RFC 6242 Using the NETCONF Protocol over Secure Shell (SSH)

Internet Engineering Task Force (IETF)                      M. Wasserman
Request for Comments: 6242                        Painless Security, LLC
Obsoletes: 4742                                                June 2011
Category: Standards Track
ISSN: 2070-1721

 

Использование протокола NETCONF на базе SSH

Using the NETCONF Protocol over Secure Shell (SSH)

PDF

Тезисы

Этот документ описывает использование протокола настройки NETCONF1 в защищенных сеансах SSH2, как подсистемы SSH. Документ отменяет действие RFC 4742.

Статус документа

Этот документ не является спецификацией проекта стандарта Internet и публикуется с информационными целями.

Документ является результатом работы IETF3 и представляет согласованное мнение сообщества IETF. Документ был вынесен на открытое обсуждение и одобрен для публикации IESG4. Не все документы, одобренные IESG, претендуют на статус тех или иных стандартов Internet (см. раздел 2 документа RFC 5741).

Информация о статусе этого документа, обнаруженных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc6242.

Авторские права

Авторские права (c) 2011 принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

Исключено в версии HTML.

1. Введение

Протокол NETCONF [RFC6241] на основе формата XML служит для настройки сетевого оборудования. Протокол NETCONF определен как сеансовый и не зависимый от транспорта с возможностью отображения на множество протоколов сеансового или транспортного уровня. В этом документе определяется использование NETCONF в сеансах SSH на основе соединений SSH [RFC4254] с транспортным протоколом SSH [RFC4253]. Это отображение позволяет пользователю или приложению применять NETCONF в защищенных сеансах.

Хотя в документе приводятся конкретные примеры передачи сообщений NETCONF через соединение SSH, применение этого транспорта не ограничивается показанными в примерах сообщениями. Этот транспорт может применяться для любых сообщений NETCONF.

2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

3. Начало работы NETCONF на базе SSH

Для запуска NETCONF на основе SSH клиент SSH сначала будет организовывать транспортное соединение SSH с использованием транспортного протокола SSH, а клиент и сервер SSH будут обмениваться ключами для защиты целостности и шифрования сообщений. После этого клиент SSH будет вызывать службу ssh-userauth для проверки подлинности пользователя в соответствии с протоколом аутентификации SSH [RFC4252]. После успешной аутентификации клиент SSH будет вызывать службу ssh-connection, называемую также протоколом соединений SSH.

Имя пользователя, представленное реализацией SSH, будет доступно уровню сообщений NETCONF (как NETCONF username) без изменения. Если имя пользователя не соответствует требованиям NETCONF [RFC6241] (т. е. не может быть представлено в XML), сессия SSH должна быть разорвана. Любые преобразования аутентифицированного отождествления клиента SSH, выполняемые сервером SSH (например, через службы аутентификации или отображение на учетные записи в системе), выходят за рамки этого документа.

После организации соединения SSH клиент будет создавать канал типа session, что приведет к организации сеанса SSH.

После организации сессии SSH клиент NETCONF будет вызывать NETCONF, как подсистему SSH с именем netconf. Поддержка подсистемы является функцией SSH версии 2 (SSHv2) и отсутствует в SSHv1. Работа NETCONF в качестве подсистемы SSH избавляет от необходимости написания сценариев (script) для распознавания системных приглашений (prompt) и позволяет пропустить дополнительную информацию тпа системных сообщений, выдаваемых при запуске интерпретатора команд (shell).

Для упрощения идентификации и фильтрации межсетевыми экранами и другими устройствами трафика NETCONF серверы NETCONF по умолчанию должны предоставлять доступ к подсистеме netconf только в случаях организации сессии SSH через выделенный IANA порт TCP 830. Серверам следует обеспечивать возможность доступа к подсистеме netconf SSH через другие порты.

Пользователь (или приложение) может применять для обращения к NETCONF, как подсистеме SSH, через выделенный IANA порт с использованием команды вида:

   [user@client]$ ssh -s server.example.org -p 830 netconf

Отметим, что опция -s задает выполнение команды netconf, как подсистемы SSH.

3.1. Обмен информацией о возможностях

Как сказано в [RFC6241], сервер NETCONF указывает свои возможности путем передачи документа XML с элементом <hello> сразу после организации сессии NETCONF. Клиент NETCONF может проанализировать это сообщения для определения возможностей NETCONF, поддерживаемых сервером NETCONF.

Как указано в [RFC6241], клиент NETCONF также передает документ XML с элементом <hello> для индикации возможностей клиента NETCONF серверу NETCONF. Документ с элементом <hello> является первым документом XML, который клиент NETCONF передает после организации сессии NETCONF.

Приведенный ниже пример показывает обмен информацией о возможностях. Данные от клиента NETCONF отмечены символами C:, а данные от сервера NETCONF — символами S:.

   S: <?xml version="1.0" encoding="UTF-8"?>
   S: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   S:   <capabilities>
   S:     <capability>
   S:       urn:ietf:params:netconf:base:1.1
   S:     </capability>
   S:     <capability>
   S:       urn:ietf:params:ns:netconf:capability:startup:1.0
   S:     </capability>
   S:   </capabilities>
   S:   <session-id>4</session-id>
   S: </hello>
   S: ]]>]]>

   C: <?xml version="1.0" encoding="UTF-8"?>
   C: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   C:   <capabilities>
   C:     <capability>
   C:       urn:ietf:params:netconf:base:1.1
   C:     </capability>
   C:   </capabilities>
   C: </hello>
   C: ]]>]]>

Хотя в примере показано, что клиент NETCONF передает сообщение <hello> вслед за аналогичным сообщением сервера, на деле обе стороны передают свои сообщения сразу после инициализации подсистемы NETCONF (возможно, одновременно).

4. Использование NETCONF на базе SSH

Сессия NETCONF на базе SSH включает клиента и сервер NETCONF, обменивающихся завершенными документами XML. После того, как сессия организована и произошел обмен информацией о возможностях, клиент NETCONF будет передавать завершенные документы XML с элементами <rpc>, а сервер будет отвечать завершенными документами XML с элементами <rpc-reply>.

4.1. Протокол кадрирования

В предыдущей версии этого документа последовательность символов ]]>]]> была определена в качестве разделителя сообщений в предположении, что такая последовательность не будет встречаться в корректных документах XML. Однако это допущение оказалось ошибочным и указанная последовательность символв может встречаться в атрибутах, комментариях и инструкциях по обработке XML. Для решения проблемы и обеспечения совместимости с имеющимися реализациями в этом документе определяется протокол кадрирования.

После сообщения <hello> должен следовать разделитель ]]>]]>. При получении сообщения <hello> приемная сторона концептуально передает его на уровень сообщений (Messages). Если обе стороны анонсировали возможность :base:1.1, далее в сессии NETCONF используется механизм кадрирования chunked (4.2. Механизм кадрирования Chunked), в противном случае — старый механизм (4.3. Механизм кадрирования End-of-Message) is used.

4.2. Механизм кадрирования Chunked

Этот механизм представляет все сообщения NETCONF с использованием chunked-кадрирования. Сообщения следуют правилу ABNF [RFC5234] Chunked-Message:

        Chunked-Message = 1*chunk
                          end-of-chunks

        chunk           = LF HASH chunk-size LF
                          chunk-data
        chunk-size      = 1*DIGIT1 0*DIGIT
        chunk-data      = 1*OCTET

        end-of-chunks   = LF HASH HASH LF

        DIGIT1          = %x31-39
        DIGIT           = %x30-39
        HASH            = %x23
        LF              = %x0A
        OCTET           = %x00-FF

Поле chunk-size представляет собой строку десятичных цифр, указывающих число октетов в chunk-data. Нули в начале поля размера не допускаются, а максимальное разрешенное значение chunk-size составляет 4294967295.

Например, сообщение

       <rpc message-id="102"
            xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <close-session/>
       </rpc>

может быть представлено в виде (\n указывает символ перевода строки LF)

   C:  \n#4\n
   C:  <rpc
   C:  \n#18\n
   C:   message-id="102"\n
   C:  \n#79\n
   C:       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">\n
   C:    <close-session/>\n
   C:  </rpc>
   C:  \n##\n

Концептуально транспортный уровень SSH кодирует сообщения, переданные уровнем Messages и декодирует сообщения из канала SSH перед их отправкой уровню Messages.

В примерах chunked-кадрирования показаны все переводы строк (LF), даже если они не являются частью механизма кадрирования. Отметим, что транспорт SSH не интерпретирует содержимого XML, т. е. не заботится о каких-либо необязательных символах LF, относящихся к XML.

Во втором и третьем блоках (chunk), показанных выше, каждая строка завершается символом LF. Для всех строк XML (кроме последней) в этом примере символы LF свитаются частью chunk-data и учитываются в chunk-size.

Отметим отсутствие LF после завершающего <rpc> тега в приведенном выше сообщении. Символ LF, требуемый в начале блока end-of-chunks, следует непосредственно за последним символом > в сообщении.

Если поле или значение chunk-size не пригодно или возникает ошибка при декодировании, партнер должен разорвать сессию NETCONF путем закрытия соответствующего канала SSH. Реализации должны гарантировать отсутствие уязвимостей, связанных с переполнением буферов.

4.3. Механизм кадрирования End-of-Message

Этот механизм поддерживается для обеспечения совместимости с реализациями предыдущих версий документа. Он применяется лишь в тех случаях, когда удаленный партнер не анонсировал базовую версию протокола с поддержкой chunked-кодирования, т. е. реализация NETCONF поддерживает лишь :base:1.0.

При использовании этого механизма клиентом и сервером должна передаваться специальная последовательность символов ]]>]]> после каждого сообщения (документ XML) в обмене NETCONF. Концептуально транспортный уровень SSH передает все данные между парой последовательностей ]]>]]> уровню Messages.

Сессия NETCONF на базе SSH с использованием совместимого с прежними версиями кадрирования end-of-message для получения набора конфигурационных данных может иметь вид:

   C: <?xml version="1.0" encoding="UTF-8"?>
   C: <rpc message-id="105"
   C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   C:   <get-config>
   C:     <source><running/></source>
   C:     <config xmlns="http://example.com/schema/1.2/config">
   C:      <users/>
   C:     </config>
   C:   </get-config>
   C: </rpc>
   C: ]]>]]>

   S: <?xml version="1.0" encoding="UTF-8"?>
   S: <rpc-reply message-id="105"
   S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   S:   <config xmlns="http://example.com/schema/1.2/config">
   S:     <users>
   S:       <user><name>root</name><type>superuser</type></user>
   S:       <user><name>fred</name><type>admin</type></user>
   S:       <user><name>barney</name><type>admin</type></user>
   S:     </users>
   S:   </config>
   S: </rpc-reply>
   S: ]]>]]>

5. Завершение работы подсистемы NETCONF

Завершение работы NETCONF обеспечивается операцией <close-session>. Сервер NETCONF обрабатывает сообщения NETCONF от клиента в порядке их поступления. Когда сервер NETCONF получает операцию <close-session>, ему ответить завершением сессии в канале SSH. Серверу NETCONF недопустимо обрабатывать какие-либо сообщения NETCONF после получения операции <close-session>.

В качестве продолжения примера из параграфа 4.2 действующая сессия подсистемы NETCONF может быть завершена, как показано в примере ниже.

   C: \n#140\n
   C: <?xml version="1.0" encoding="UTF-8"?>\n
   C: <rpc message-id="106"\n
   C:      xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">\n
   C:   <close-session/>\n
   C: </rpc>
   C: \n##\n

   S: \n#139\n
   S: <?xml version="1.0" encoding="UTF-8"?>\n
   S: <rpc-reply id="106"\n
   S:            xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">\n
   S:   <ok/>\n
   S: </rpc-reply>
   S: \n##\n

6. Вопросы безопасности

Протокол NETCONF применяется для доступа к конфигурационным параметрам и данным состояния для изменения параметров конфигурации, поэтому возможности такого доступа должны предоставляться лишь пользователям или системам, уполномоченным видеть такие данные или менять конфигурацию сервера NETCONF (сетевого устройства).

Для идентификации сервер SSH должен быть проверен и аутентифицирован клиентом SSH в соответствии с локальной политикой до того, как от сервера будут переданы или приняты какие-либо данные парольной аутентификации, конфигурационные параметры или данные состояния. Для идентификации клиента SSH он также должен быть проверен и аутентифицирован сервером SSH в соответствии с локальной политикой для подтверждения легитимности входящего запроса клиента до начала обмена с ним конфигурационными параметрами или данными состояния. Ни одной из сторон не следует организовывать соединения NETCONF на базе SSH с неизвестным, неожиданным или некорректным отождествлением противоположной стороны.

Данные конфигурации или состояния могут включать конфиденциальную информацию типа имен пользователей или ключей защиты. Поэтому для работы NETCONF требуются коммуникационные каналы, обеспечивающие надежное шифрование для защиты конфиденциальности данных. Этот документ определяет работу протокола NETCONF с использованием отображения SSH, которое поддерживает стойкое шифрования и проверку подлинности.

Данный документ требует, чтобы серверы SSH по умолчанию предоставляли доступ к подсистеме SSH netconf лишь через специальный порт TCP, выделенный IANA для этой цели. Это позволяет идентифицировать и фильтровать трафик NETCONF на базе SSH в межсетевых экранах и других устройствах. Однако это дает возможность атакующему легко идентифицировать трафик NETCONF на базе SSH.

Документ также рекомендует серверам SSH обеспечивать возможность настройки доступа к подсистеме netconf через другие порты. Использование такой конфигурации без соответствующей настройки межсетевых экранов и других устройств может приводить к получения доступа не уполномоченных узлов к подсистеме netconf через межсетевой экран или иную административную границу.

В RFC 4742 принято допущение о том, что последовательность EOM5 ]]>]]> не может появляться в корректно сформированных документах XML, однако это оказалось ошибкой. Последовательность EOM может вызывать проблемы в работе и открывает возможность для атак с использованием специально подготовленных сообщений RPC. Однако эта угроза не представляет опасной. Этот документ продолжает использовать последовательность EOM в начальном сообщении <hello> для предотвращения несовместимости с имеющимися реализациями. Когда обестороны соединения поддерживают возможность :base:1.1, в сессии NETCONF после приветствия применяется специальное кадрирование (4.2. Механизм кадрирования Chunked), позволяющее предотвратить атаки со вставкой фиктивных сообщений.

7. Взаимодействие с IANA

На основе предыдущей версии этого документа (RFC 4742) агентство IANA выделило порт TCP с номером 830 для принятого по умолчанию порта в сессиях NETCONF на базе SSH.

Агентство IANA также выделило идентификатор netconf в качестве имени подсистемы SSH (SSH Subsystem Name), как указано в [RFC4250]

Имя подсистемы

Документ

netconf

RFC 4742

Агентство IANA в своих реестрах обновило информацию со ссылкой на этот документ.

8. Благодарности

Ted Goddard был соавтором предыдущих версий этого документа.

Документ был создан с помощью инструмента xml2rfc, описанного в RFC 2629 [RFC2629].

Вного полезных предложений было получено от других членов группы разработчиков NETCONF, включая Andy Bierman, Weijing Chen, Rob Enns, Wes Hardaker, David Harrington, Eliot Lear, Simon Leinen, Phil Shafer, Juergen Schoenwaelder и Steve Waldbusser. Значительную помощь оказали также рецензии Olafur Gudmundsson, Sam Hartman, Scott Hollenbeck, Bill Sommerfeld, Balazs Lengyel, Bert Wijnen, Mehmet Ersue, Martin Bjorklund, Lada Lothka, Kent Watsen и Tom Petch.

9. Литература

9.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC4250] Lehtinen, S. and C. Lonvick, «The Secure Shell (SSH) Protocol Assigned Numbers», RFC 4250, January 2006.

[RFC4252] Ylonen, T. and C. Lonvick, «The Secure Shell (SSH) Authentication Protocol», RFC 4252, January 2006.

[RFC4253] Ylonen, T. and C. Lonvick, «The Secure Shell (SSH) Transport Layer Protocol», RFC 4253, January 2006.

[RFC4254] Ylonen, T. and C. Lonvick, «The Secure Shell (SSH) Connection Protocol», RFC 4254, January 2006.

[RFC5234] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, June 2011.

9.2. Дополнительная литература

[RFC2629] Rose, M., «Writing I-Ds and RFCs using XML», RFC 2629, June 1999.

Приложение A. Отличия от RFC 4742

В этом приложении перечислены основные отличия этого документа от RFC 4742.

  • Добавлен механизм кадрирования chunked для решения проблемы безопасности, связанной с EOM.

  • Расширен раздел «Вопросы безопасности» с включением текста, посвященного проблеме EOM.

  • Добавлены примеры, иллюстрирующие новое chunked-кодирование, уточнено применение символов перевода строки.

  • Добавлен текст об обработке имен пользователей NETCONF в соответствии с требованиями [RFC6241].

  • Термины client/server и manager/agent заменены на SSH client/server и NETCONF client/server.

  • Используется термин operation (операция) вместо command или message.

  • Учтены ошибки, обнаруженные в RFC 4742 с моменту публикации этого документа (см ошибки RFC 4742 на сайте http://www.rfc-editor.org).


Адрес автора

Margaret Wasserman

Painless Security, LLC

356 Abbott Street

North Andover, MA 01845

USA

Phone: +1 781 405-7464

EMail: mrw@painless-security.com

URI: http://www.painless-security.com

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1Network Configuration Protocol.

2Secure Shell — защищенная командная оболочка (среда).

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5End-of-message — конец сообщения.




RFC 6241 (часть 2)

Часть 1.


8. Возможности

В этом разделе определяется набор возможностей, которые могут применять клиент и сервер. Каждый партнер анонсирует свои возможности, указывая их в процессе начального согласования. От каждого партнера требуется понимание лишь тех возможностей, которые он может применять, и он должен игнорировать полученные от другого партнера возможности, которые ему не требуются или непонятны.

Дополнительные возможности могут определяться с использованием шаблона, описанного в Приложении D. Будущие определения возможностей могут публиковаться органами стандартизации или в виде фирменных расширений.

Возможности NETCONF указываются идентификаторами URI. Базовые возможности определяются с использованием идентификаторов URN в соответствии с методом, описанным в RFC 3553 [RFC3553]. Определенные в этом документе возможности используют формат

      urn:ietf:params:netconf:capability:{name}:1.x

где {name} указывает имя возможности. В обсуждениях и почтовых сообщениях возможности часто указываются в сокращенном виде :{name} или :{name}:{version}, если существует несколько версий возможности. Например, возможность foo будет иметь формальное имя urn:ietf:params:netconf:capability:foo:1.0, и сокрашенное :foo. Сокращенную форму недопустимо применять в протоколе.

8.1. Обмен данными о возможностях

Возможности анонсируются в сообщениях, переданных каждым партнером в процессе организации сессии. Когда сеанс NETCONF организован, каждый партнер (и клиент, и сервер) должен передать элемент <hello> содержащий список поддерживаемых возможностей. Каждый из партнеров должен анонсировать по меньшей мере базовую возможность NETCONF urn:ietf:params:netconf:base:1.1. Партнеры могут включать возможности из предыдущих версий NETCONF для индикации поддержки разных версий протокола.

Партнеры должны убедиться в наличии поддерживаемой обоими версии протокола. При сравнении URI версии протокола используется только компонента base, если в конце строки возможностей представлены дополнительные параметры. Если общей версии не найдено, партнерам NETCONF недопустимо продолжать сессию. Если в URI указано несколько версий протокола, должна выбираться старшая (наиболее свежая) версия, поддерживаемая обоими партнерами.

Сервер, передающий элемент <hello>, должен включать в него элемент <session-id> с идентификатором данной сессии NETCONF. Клиенту при передаче элемента <hello> недопустимо включать в него элемент <session-id>.

Сервер, получивший сообщение <hello> с элементом <session-id>, должен прервать сессию NETCONF. Аналогично, клиент, не получивший элемент <session-id> в сообщении <hello> от сервера, должен прервать сессию NETCONF (без отправки <close-session>).

В приведенном ниже примере сервер анонсирует базовые возможности NETCONF, одну дополнительную возможность из базовой спецификации NETCONF и одну дополнительную возможность данного сервера.

   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capabilities>
       <capability>
         urn:ietf:params:netconf:base:1.1
       </capability>
       <capability>
         urn:ietf:params:netconf:capability:startup:1.0
       </capability>
       <capability>
         http://example.net/router/2.3/myfeature
       </capability>
     </capabilities>
     <session-id>4</session-id>
   </hello>

Каждый из партнеров передает сообщение <hello> сразу после организации соединения. Партнерам недопустимо ждать приветствия от другой стороны перед отправкой своего.

8.2. Возможность записи в рабочую конфигурацию

8.2.1. Описание

Возможность :writable-running говорит о том, что устройство поддерживает непосредственную запись в хранилище конфигурации <running>. Иными словами, устройство поддерживает операции <edit-config> и <copy-config> с целевым хранилищем <running>.

8.2.2. Зависимости

Нет.

8.2.3. Идентификатор возможности

Возможность :writable-running указывается строкой

      urn:ietf:params:netconf:capability:writable-running:1.0

8.2.4. Новые операции

Нет.

8.2.5. Изменения существующих операций

8.2.5.1. <edit-config>

Возможность :writable-running меняет операцию <edit-config>, позволяя указывать элемент <running> в качестве <target>.

8.2.5.2. <copy-config>

Возможность :writable-running меняет операцию <copy-config>, позволяя указывать элемент <running> в качестве <target>.

8.3. Поддержка конфигурации-кандидата

8.3.1. Описание

Возможность :candidate указывает поддержку устройством дополнительного хранилища конфигурации, служащего для хранения конфигурационных данных, которыми можно манипулировать без влияния на текущую конфигурацию устройства. Хранилище-кандидат содержит полный набор конфигурационных данных и позволяет манипулировать ими. Операции добавление, удаления или изменения конфигурационных данных позволяют создать желаемую конфигурацию. Опреация <commit> может быть вызвана в любой момент для подачи этих данных в рабочую конфигурацию устройства.

Операция <commit> представляет текущее содержимое конфигурации-кандидата в рабочую конфигурацию устройства. Хотя это представление выглядит простым копированием, оно выделена в специальную операцию по Сохранение концепции верхнего уровня как операции первого класса, позволяет разработчикам более ясно представлять, что запрашивает клиент и что должен выполнить сервер. Это делает цели более понятными, специальные случаи менее сложными, а взаимодействие операций более прямым. Например, возможность :confirmed-commit:1.1 (параграф 8.4) не имеет смысла в качестве операции подтверждаемого копирования (copy confirmed).

Конфигурация-кандидат допускает совместное использование в нескольких сеансах. Пока у клиента нет конкретной информации о том, что конфигурация-кандидат не используется в других сессиях, он должен предполагать возможность ее одновременного изменения в других сессиях. Поэтому клиенту разумно блокировать конфигурацию-кандидат перед ее изменением.

Клиент может отказаться от непредставленных изменений конфигурации-кандидата с помощью операции <discard-changes>. Эта операция вернет содержимое конфигурации-кандидата в состояние рабочей конфигурации.

8.3.2. Зависимости

Нет.

8.3.3. Идентификатор возможности

Возможность :candidate указывается строкой

      urn:ietf:params:netconf:capability:candidate:1.0

8.3.4. Новая операция

8.3.4.1. <commit>

Описание

Когда содержимое хранилища-кандидата полностью подготовлено, данные из него могут быть представлены (commit) устройству для их проверки и подтверждения пригодности.

Для представления конфигурации-кандидата в качестве новой текущей конфигурации устройства служит операция <commit>.

Эта операция предлагает устройству реализовать данные конфигурации-кандидата. Если устройство не способно реализовать все изменения, предложенные конфигурацией-кандидатом, оно должно сохранить прежнюю конфигурацию. Если устройство может применить предложенную конфигурацию полностью, рабочая конфигурация должна быть заменена кодержимым конфигурации-кандидата.

Если рабочая или предлагаемая конфигурация в данный момент заблокирована другой сессией, операция <commit> должна привести к отказу и отправке <error-tag> со значением in-use.

Если система не поддерживает возможность :candidate, операция <commit> будет недоступна.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <commit/>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>
8.3.4.2. <discard-changes>

Если клиент решил отказаться от представления конфигурации-кандидата, он может использовать операцию <discard-changes> для копирования в конфигурацию-кандидат содержимого рабочей конфигурации.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <discard-changes/>
     </rpc>

Эта операция отбрасывает все не представленные изменения конфигурации-кандидата и возвращает ту в состояние рабочей конфигурации.

8.3.5. Изменение существующий операций

8.3.5.1. <get-config>, <edit-config>, <copy-config>, <validate>

Конфигурация-кандидат может служить в качестве источника или цели в любой из операций <get-config>, <edit-config>, <copy-config> и <validate> при ее задании параметром <source> или <target>, соответственно. Для указания этой конфигурации служит элемент <candidate>.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <candidate/>
         </source>
       </get-config>
     </rpc>
8.3.5.2. <lock> и <unlock>

Конфигурация-кандидат может быть заблокирована операцией <lock> при указании элемента <candidate> в качестве параметра <target>.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <lock>
         <target>
           <candidate/>
         </target>
       </lock>
     </rpc>

Для снятия блокировки конфигурации-кандидата служит операция <unlock> с элементом <candidate> в качестве параметра <target>.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <unlock>
         <target>
           <candidate/>
         </target>
       </unlock>
     </rpc>

При отказе клиента с несохраненными изменениями конфигурации кандидата восстановление может оказаться сложным. Для упрощения восстановления все несохраненные изменения отбрасываются при снятии блокировки в результате явного вызова операции <unlock> или неявно при отказе в сессии.

8.4. Подтверждаемое представление

8.4.1. Описание

Возможность :confirmed-commit:1.1 показывает поддержку сервером операции <cancel-commit> и параметров <confirmed>, <confirm-timeout>, <persist>, <persist-id> для операции <commit> (см. параграф 8.3).

Подтверждаемая операция <commit> должна быть отменена, если подтверждающая подача (commit) не состоялась в течение заданного интервала (по умолчанию 600 секунд = 10 минут). Подтвержденная подача — это операция <commit> без параметра <confirmed>. Интервал ожидания можно изменить с помощью параметра <confirm-timeout>. Если до истечения срока была введена следующая подтверждаемая операция <commit>, таймер сбрасывается в новое значение (по умолчанию 600 секунд). И подтверждающая подача и следующая подтверждаемая операция <commit> могут вносить в конфигурацию дополнительные изменения.

Если в подтверждаемой операции подачи не задан элемент <persist>, любая последующая подтверждаемая подача и подтверждающая подача должны выполняться в той же сессии, где была введена подтверждаемая подача. Если элемент <persist> задан в подтверждаемой операции <commit>, следующая подача и подтверждающая подача могут выполняться из любой сессии и должны включать элемент <persist-id> значение которого совпадает со значением элемента <persist>.

Если сервер анонсирует также способность :startup, требуется также операция <copy-config> для копирования из рабочего хранилища в стартовое для сохранения изменений при перезагрузке устройства.

Если сессия, вызвавшая подтверждаемую подачу, была по какой-либо причине прервана до наступления тайм-аута подтверждения, сервер должен восстановить конфигурацию, которая была до подачи, если подтверждаемая подача не включала также элемент <persist>.

Если устройство по какой-либо перезагружается до завершения впемени ожидания, сервер должен восстановить конфигурацию, которая была до подтверждаемого представления.

Если подтверждающее представление не введено, устройство будет возвращаться к конфигурации, которая была до ввода подтверждаемого представления. Для отказа от подтверждаемого представление и восстановления конфигурации, которая была до того, клиент может явно восстановить конфигурацию с помощью операции <cancel-commit>.

Для совместно используемых конфигураций эта возможность может приводить к непреднамеренному удалению чужих изменений (например, в других сессиях NETCONF), если не используется функция блокировки конфигурации (т. е. блокировка организована до начала работы операции <edit-config>). Поэтому при использовании этой функции с общими конфигурационными хранилищами следует также применять блокировку конфигурации.

Версия 1.0 этой возможности была определена в [RFC4741]. Этот документ определяет версию 1.1, которая расширяет версию 1.0 путем добавления новой операции <cancel-commit> и двух новых необязательных параметров <persist> и <persist-id>. Для совместимости со старыми клиентами серверы, поддерживающие эту спецификацию, могут анонсировать версию 1.0 в дополнение к версии 1.1.

8.4.2. Зависимости

Возможность :confirmed-commit:1.1 имеет смысл только при наличии поддержки возможности :candidate.

8.4.3. Идентификатор возможности

Возможность :confirmed-commit:1.1 указывается строкой

      urn:ietf:params:netconf:capability:confirmed-commit:1.1

8.4.4. Новые операции

8.4.4.1. <cancel-commit>

Описание

Отменяет подтверждаемую подачу конфигурации. Если параметр <persist-id> не задан, опреация <cancel-commit> должна быть введена в той же сессии, что и подтверждаемое представление.

Параметры

persist-id

Отменяет устойчивую к разрыву сессии подтверждаемую подачу конфигурации. Значение должно совпадать со значением параметра <persist> в операции <commit>. Если значения различаются, операция завершается отказом с ошибкой invalid-value.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <commit>
         <confirmed/>
       </commit>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

     <rpc message-id="102"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <cancel-commit/>
     </rpc>

     <rpc-reply message-id="102"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

8.4.5. Изменение существующих операций

8.4.5.1. <commit>

Возможность :confirmed-commit:1.1 добавляет 4 новых параметра для операции <commit>.

Параметры

confirmed

Выполнить подтверждаемую операцию <commit>.

confirm-timeout

Время ожидания для подтверждаемого представления (в секундах). Если тайм-аут на задан, время ожидания составит 600 секнд.

persist

Делает подтверждаемое представление устойчивым к разрыву сессии и устанавливает маркер для выполняющегося подтверждаемого представления.

persist-id

Используется в следующем подтверждаемом представлении или в подтверждающем представлении из любой сессии с маркером предыдущей операции <commit>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <commit>
         <confirmed/>
         <confirm-timeout>120</confirm-timeout>
       </commit>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

Пример

     <!-- начало устойчивой к разрыву сессии операции confirmed-commit -->
     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <commit>
         <confirmed/>
         <persist>IQ,d4668</persist>
       </commit>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

     <!-- подтверждение устойчивой к разрыву сессии операции confirmed-commit,
          confirmed-commit, возможно из другой сессии -->
     <rpc message-id="102"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <commit>
         <persist-id>IQ,d4668</persist-id>
       </commit>
     </rpc>

     <rpc-reply message-id="102"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

8.5. Возможность отката после ошибки

8.5.1. Описание

Эта возможность говорит о поддержке сервером значения rollback-on-error для параметра <error-option> операции <edit-config>.

Для совместно используемых конфигураций эта возможность может приводить к непреднамеренному удалению чужих изменений (например, в других сессиях NETCONF), если не используется функция блокировки конфигурации (т. е. блокировка организована до начала работы операции <edit-config>). Поэтому при использовании этой функции с общими конфигурационными хранилищами следует также применять блокировку конфигурации.

8.5.2. Зависимости

Нет.

8.5.3. Идентификатор возможности

Возможность :rollback-on-error указывается строкой

      urn:ietf:params:netconf:capability:rollback-on-error:1.0

8.5.4. Новые операции

Нет.

8.5.5. Изменения существующих операций

8.5.5.1. <edit-config>

Возможность :rollback-on-error позволяет указывать значение rollback-on-error для параметра <error-option> операции <edit-config>.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <error-option>rollback-on-error</error-option>
         <config>
           <top xmlns="http://example.com/schema/1.2/config">
             <interface>
               <name>Ethernet0/0</name>
               <mtu>100000</mtu>
             </interface>
           </top>
         </config>
       </edit-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

8.6. Проверка пригодности

8.6.1. Описание

Проверка пригодности представляет собой полную проверку конфигурации на предмет наличия синтаксических и семантический ошибок до применения этой конфинурации в устройстве.

Анонсирование этой возможности означает поддержку протокольной операции <validate> и проверки по крайней мере синтаксических ошибок. Кроме того, эта возможность поддерживает параметр <test-option> для операции <edit-config>, который задает проверку по крайней мере синтаксических ошибок.

Версия 1.0 этой возможности была определена в [RFC4741]. Описанная здесь версия 1.1 расширяет версию 1.0 путем добавления значения test-only для параметра <test-option> операции <edit-config>. Для совместимости со старыми клиентами серверы, поддерживающие эту спецификацию, могут анонсировать версию 1.0 в дополнение к версии 1.1.

8.6.2. Зависимости

Нет.

8.6.3. Идентификатор возможности

Возможность :validate:1.1 указывается строкой

      urn:ietf:params:netconf:capability:validate:1.1

8.6.4. Новые операции

8.6.4.1. <validate>

Описание

Эта протокольная операция проверяет пригодность содержимого указанной конфигурации.

Параметры

source

Имя конфигурационного хранилища для проверки (например, <candidate>) или элемент <config>, содержащий полную конфигурацию для проверки.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Опреация <validate> может завершаться отказом по разным причинам типа синтаксических ошибок, пропущенных параметров, ссылок не неопределенные данные конфигурации и других нарушений правил, заданных базовой моделью.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <validate>
         <source>
           <candidate/>
         </source>
       </validate>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

8.6.5. Изменения существующих операций

8.6.5.1. <edit-config>

Возможность :validate:1.1 меняет операцию <edit-config>, позволяя принимать параметр <test-option>.

8.7. Раздельное стартовое хранилище

8.7.1. Описание

Устройство поддерживает разные хранилища для рабочей и стартовой конфигурации. Стартовая конфигурация используется при загрузке устройства. Операции, воздействующие на рабочее хранилище, не будут автоматически копироваться в стартовую конфигурацию. Явная операция <copy-config> из хранилища <running> в <startup> служит для обновления стартовой конфигурации в соответствии с текущим содержимым рабочей конфигурации. Операции протокола NETCONF указывают стартовое хранилище с помощью элемента <startup>.

8.7.2. Зависимости

Нет.

8.7.3. Идентификатор возможности

Возможность :startup указывается строкой

      urn:ietf:params:netconf:capability:startup:1.0

8.7.4. Новые операции

Нет.

8.7.5. Изменения существующих операций

8.7.5.1. General

Возможность :startup добавляет конфигурационное хранилище <startup/> к аргументам некоторых операций NETCONF. Сервер должен поддерживать это значение для указанных в таблице парметров.

Операция

Параметры

Примечания

<get-config>

<source>

<copy-config>

<source> <target>

<lock>

<target>

<unlock>

<target>

<validate>

<source>

Если анонсирована возможность :validate:1.1

<delete-config>

<target>

Сбрасывает устроство в заводские установки

Для записи стартовой конфигурации используется команда <copy-config>, копирующая содержимое хранилища <running> в хранилище <startup>.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <copy-config>
         <target>
           <startup/>
         </target>
         <source>
           <running/>
         </source>
       </copy-config>
     </rpc>

8.8. Поддержка URL

8.8.1. Описание

Узел NETCONF может поддерживать элемент <url> в качестве значения параметров <source> и <target>. Эта возможность дополнительно идентифицируется аргументами URL, указывающими поддерживаемые схемы URL.

8.8.2. Зависимости

Нет.

8.8.3. Идентификатор возможности

Возможность :url указывается строкой

      urn:ietf:params:netconf:capability:url:1.0?scheme={name,...}

Идентификатор URI возможность :url должен включать аргумент scheme, содержащий список разделенных запятыми имен схем, поддерживаемых узлом NETCONF. Например,

      urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file

8.8.4. Новые операции

Нет.

8.8.5. Изменения существующих операций

8.8.5.1. <edit-config>

Возможность :url меняет операцию <edit-config>, позволяя той принимать элемент <url> в качестве параметра <config>.

Файл, на который указывает url в качестве содержимого конфигурационных данных для редактирования, кодируется в формате XML внутри элемента <config> в пространстве имен urn:ietf:params:xml:ns:netconf:base:1.0.

8.8.5.2. <copy-config>

Возможность :url меняет операцию <copy-config>, позволяя той принимать элемент <url> в качестве параметров <source> и <target>.

Файл, на который указывает url в качестве полного конфигурационного хранилища, кодируется в формате XML внутри элемента <config> в пространстве имен urn:ietf:params:xml:ns:netconf:base:1.0.

8.8.5.3. <delete-config>

Возможность :url меняет операцию <delete-config>, позволяя ей принимать элемент <url> в качестве параметра <target>.

8.8.5.4. <validate>

Возможность :url меняет операцию <validate>, позволяя ей принимать элемент <url> в качестве параметра <source>.

8.9. Выражения XPath

8.9.1. Описание

Возможность XPath показывает, что узел NETCONF поддерживает использование выражений XPath в элементах <filter>. Описание XPath приведено в [W3C.REC-xpath-19991116].

Модель данных в выражениях XPath совпадает с используемой в XPath 1.0 [W3C.REC-xpath-19991116] с тем же расширением для потомков корневого узла, которое применяется в XSLT 1.0 ([W3C.REC-xslt-19991116], параграф 3.1). В частности, это означает, что корневой узел может иметь в качестве потомков любое число элементов.

Выражения XPath оцениваются в следующем контексте:

  • набор объявлений пространств имен составляют те, которые относятсе к зоне действия элемента <filter>;

  • набор привязок переменных определяется моделью данных и будет пуст, если привязки не заданы;

  • библиотекой функций является основная библиотека, дополненная функциями модели данных;

  • узлом контекста является корневой узел.

Выражение XPath должно возвращать набор узлов. Если этого не происходит, операция завершается отказом с ошибкой invalid-value.

Сообщение с откликом содержит ветки (subtree), выбранные фильтром. Для каждой такой ветви путь от корня модели данных вниз к ветви, включая все элементы или атрибуты, необходимые для однозначной идентификации ветви, включает в отклик. Конкретные экземпляры данных не дублируются в отклике.

8.9.2. Зависимости

Нет.

8.9.3. Идентификатор возможности

Возможность :xpath указывается строкой

      urn:ietf:params:netconf:capability:xpath:1.0

8.9.4. Новые операции

Нет.

8.9.5. Изменения существующих операций

8.9.5.1. <get-config> и <get>

Возможность :xpath меняет операции <get> и <get-config>, позволяя им принимать значение xpath в атрибуте type элемента <filter>. Если атрибут type имеет значение xpath, в элементе <filter> должен присутствовать атрибут select, который будет считаться выражением XPath и применяться для фильтрации возвращаемых данных .В таком случае сам элемент <filter> должен быть пустым.

Результатом XPath для выбора должен быть набор узлов (node-set). Каждый узел в node-set Должен соответствовать узлу в базовой модели данных. Для корректной идентификации каждого узла служат приведенные ниже правила.

  • Все узлы-предки в результате должны кодироваться первыми, чтобы элемент <data>, возвращаемый в отклике содержал лишь полностью заданные ветви в соответствии с базовой моделью данных.

  • Если любые братские или родительские узлы в результате нужны для идентификации конкретного экземпляра в концептуальной структуре данных, эти узлы также должны быть пердставлены в отклике.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <!-- найти пользователя с именем named fred -->
         <filter xmlns:t="http://example.com/schema/1.2/config"
                 type="xpath"
                 select="/t:top/t:users/t:user[t:name='fred']"/>
        </get-config>
     </rpc>

     <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>fred</name>
               <company-info>
                 <id>2</id>
               </company-info>
             </user>
           </users>
         </top>
       </data>
     </rpc-reply>

9. Вопросы безопасности

В этом разделе рассматриваются вопросы безопасности базового уровня сообщений NETCONF и базовых операций протокола NETCONF. Вопросы безопасности транспорта NETCONF рассмотрены в соответствующих транспортных протоколах, а безопасность содержимого, с которым работает NETCONF, в документах, определяющих модели данных.

Этот документ не задает схемы проверки и предоставления полномочий (authorization), поскольку такая схема будет скорей всего связана с моделью данных или метаданных. Разработчика следует обеспечивать полнофункциональную схему контроля полномочий для NETCONF.

Проверка полномочий отдельного пользователя сервером NETCONF может (но не обязательно) отображаться (1:1) на дугие интерфейсы. Во-первых, модели данных могут быть несоместимы. Во-вторых, может оказаться желательным проверка полномочий на основе механизмов, доступных на уровне защищенного транспорта (например, SSH, BEEP1 и т. п.).

Кроме того, оперции с данными конфигурации могут приводить к нежелательным последствиям, если эти операции не защищены также глобальной блокировкой фалов или объектов, с которыми операция имеет дело. Например, если рабочую конфигурацию не заблокировать, может быть представлен неполный список контроля доступа из конфигурации-кандидата, ведущий к снижению уровня безопасности или даже к недоступности устройства.

Конфигурационные данные по своей природе конфиденциальна. Ее передача в открытом виде без контроля целостности оставляет устройство открытым для классических атак с перехватом и вставкой фальсифицированных данных. Конфигурационные данные часто включают пароли, имена пользователей, описания услуг и топологические сведения, которые являются конфиденциальными. По этой причине данный протокол следует реализовать с адекватным учетом всех возможных атак.

По этим причинам протокол должен обеспечивать минимальную поддержку конфиденциальности и проверки подлинности. Предполагается, что базовый транспорт (SSH, BEEP и т. п.) будет обеспечивать требуемые услуги конфиденциальности и проверки подлинности. Предполагается также, что отждествление каждой стороны сессии NETCONF будет доступно другой стороне для контроля доступа при выполнении запросов. Можно также легко представить дополнительные методы для контроля полномочий. Протокол NETCONF, сам по себе, не предоставляет никаких средств повторной или первичной проверки подлинности. Все такие действия происходят на нижележащем уровне.

В разных средах могут предоставляться разные права до и после проверки подлинности. Поэтому модель проверки подлинности в документе не задана. Когда операцию пытаются выполнить без должных полномочий, достаточно простого отказа в доступе (access denied). Отметим, что обмен информацией о правах доступа, может происходить в форме обмена конфигурационными данными, что дополнительно усиливает требования по защите соединений.

Следует подчеркнуть важность понимания того, что разные операции по своей природе имеют разный уровнеь «деликатности». Например, операция <copy-config> для стартовой или рабочей конфигурации явно не является обычной операцией инициализации, как <edit-config>. Такие глобальные операции должны запрещать изменение данных лицам, не имеющим на то полномочий. Например, если пользователь A не имеет права настраивать адрес IP на интерфейсе, а пользователь B настраивает такой адрес в конфигурации <candidate>, пользователю A недопустимо разрешать представление конфигурации <candidate>.

Точно так же, если кто-то скажет: «запишите конфигурацию, хранящуюся по ссылке URL,» — этого не следует делать без должной проверки полномочий.

Операция <lock> показывает, что протокол NETCONF предназначен для использования системами, которым администратор имеет некое доверие. Как указано в этом документе, можно заблокировать части конфигурации, что сделает их недоступными для других. В конечном итоге может быть заблокирована конфигурация целиком. Для смягчения этой проблемы есть два подхода. Можно «убить» другую сессию NETCONF программными средствами в рамках протокола NETCONF, если идентификатор этой сессии известен. Другим вариантом является снятие блокировки с использованием пользовательского интерфейса самого устройства. Эти два механизма могут действовать один против другого, что может быть устранено путем удаления нарушителя с сервера AAA2. Однако такое решение удобно не во всех случаях (например, при использовании парных ключей SSH).

10. Взаимодействие с IANA

10.1. Пространство имен NETCONF XML

Этот документ регистрирует URI для пространства имен NETCONF XML в реестре IETF XML [RFC3688].

Агентство IANA обновиле приведенные ниже URI со ссылками на этот документ.

   URI: urn:ietf:params:xml:ns:netconf:base:1.0
   Registrant Contact: The IESG.
   XML: N/A, the requested URI is an XML namespace.

10.2. Схема NETCONF XML

Этот документ регистрирует URI для схемы NETCONF XML в реестре IETF XML [RFC3688].

Агентство IANA обновиле приведенные ниже URI со ссылками на этот документ.

   URI: urn:ietf:params:xml:schema:netconf
   Registrant Contact: The IESG.
   XML: Appendix B of this document.

10.3. Модуль для YANG NETCONF

Этот документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020].

     name:        ietf-netconf
     namespace:   urn:ietf:params:xml:ns:netconf:base:1.0
     prefix:      nc
     reference:   RFC 6241

10.4. URN для возможностей NETCONF

Агенство IANA создало и поддерживает реестр Network Configuration Protocol (NETCONF) Capability URNs для идентификаторов возможностей NETCONF. Добавление в этот реестр выполняется по процедуре IETF Standards Action.

Агентство IANA обновило в реестре перечисленные в таблице возможности со ссылками на этот документ.

Индекс

Идентификатор возможности

:writable-running

urn:ietf:params:netconf:capability:writable-running:1.0

:candidate

urn:ietf:params:netconf:capability:candidate:1.0

:rollback-on-error

urn:ietf:params:netconf:capability:rollback-on-error:1.0

:startup

urn:ietf:params:netconf:capability:startup:1.0

:url

urn:ietf:params:netconf:capability:url:1.0

:xpath

urn:ietf:params:netconf:capability:xpath:1.0

В реестр добавлены также перечисленные в следующей таблице возможности.

Индекс

Идентификатор возможности

:base:1.1

urn:ietf:params:netconf:base:1.1

:confirmed-commit:1.1

urn:ietf:params:netconf:capability:confirmed-commit:1.1

:validate:1.1

urn:ietf:params:netconf:capability:validate:1.1

11. Авторы

Кроме редакторов в написании этого документа принимали участие

Ken Crozier, Cisco Systems;

Ted Goddard, IceSoft;

Eliot Lear, Cisco Systems;

Phil Shafer, Juniper Networks;

Steve Waldbusser;

Margaret Wasserman, Painless Security, LLC.

12. Благодарности

Авторы признательны члена рабочей группы NETCONF. В частнсти, авторы благодарны Wes Hardaker за настойчивость и терпение при разъяснении вопросов безопасности. Спасибо также Randy Presuhn, Sharon Chisholm, Glenn Waters, David Perkins, Weijing Chen, Simon Leinen, Keith Allen, Dave Harrington, Ladislav Lhotka, Tom Petch и Kent Watsen за их ценные советы.

13. Литература

13.1. Номативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, «An IETF URN Sub-namespace for Registered Protocol Parameters», BCP 73, RFC 3553, June 2003.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 2003.

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, January 2004.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

[RFC5717] Lengyel, B. and M. Bjorklund, «Partial Lock Remote Procedure Call (RPC) for NETCONF», RFC 5717, December 2009.

[RFC6020] Bjorklund, M., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 60203, October 2010.

[RFC6021] Schoenwaelder, J., «Common YANG Data Types», RFC 6021, October 2010.

[RFC6242] Wasserman, M., «Using the NETCONF Configuration Protocol over Secure Shell (SSH)», RFC 6242, June 2011.

[W3C.REC-xml-20001006] Sperberg-McQueen, C., Bray, T., Paoli, J., and E. Maler, «Extensible Markup Language (XML) 1.0 (Second Edition)», World Wide Web Consortium REC-xml-20001006, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>4.

[W3C.REC-xpath-19991116] DeRose, S. and J. Clark, «XML Path Language (Xpath) Version 1.0», World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.

13.2. Дополнительная литература

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, «Remote Authentication Dial In User Service (RADIUS)», RFC 2865, June 2000.

[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, «Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols», BCP 70, RFC 3470, January 2003.

[RFC4251] Ylonen, T. and C. Lonvick, «The Secure Shell (SSH) Protocol Architecture», RFC 4251, January 2006.

[RFC4741] Enns, R., «NETCONF Configuration Protocol», RFC 4741, December 2006.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, August 2008.

[W3C.REC-xslt-19991116] Clark, J., «XSL Transformations (XSLT) Version 1.0», World Wide Web Consortium Recommendation REC-xslt-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xslt-19991116>.

Приложение A. Список ошибок NETCONF

Это приложение является нормативным.

Для каждого error-tag указаны действительные значения error-type и error-severity вместе с обязательными данными error-info, если они есть.

   error-tag:      in-use
   error-type:     protocol, application
   error-severity: error
   error-info:     none
   Description:    The request requires a resource that already is in use.

   error-tag:      invalid-value
   error-type:     protocol, application
   error-severity: error
   error-info:     none
   Description:    The request specifies an unacceptable value for one or more parameters.

   error-tag:      too-big
   error-type:     transport, rpc, protocol, application
   error-severity: error
   error-info:     none
   Description:    The request or response (that would be generated) is
                   too large for the implementation to handle.

   error-tag:      missing-attribute
   error-type:     rpc, protocol, application
   error-severity: error
   error-info:     <bad-attribute> : name of the missing attribute
                   <bad-element> : name of the element that is supposed
                     to contain the missing attribute
   Description:    An expected attribute is missing.

   error-tag:      bad-attribute
   error-type:     rpc, protocol, application
   error-severity: error
   error-info:     <bad-attribute> : name of the attribute w/ bad value
                   <bad-element> : name of the element that contains
                     the attribute with the bad value
   Description:    An attribute value is not correct; e.g., wrong type,
                   out of range, pattern mismatch.

   error-tag:      unknown-attribute
   error-type:     rpc, protocol, application
   error-severity: error
   error-info:     <bad-attribute> : name of the unexpected attribute
                   <bad-element> : name of the element that contains
                     the unexpected attribute
   Description:    An unexpected attribute is present.

   error-tag:      missing-element
   error-type:     protocol, application
   error-severity: error
   error-info:     <bad-element> : name of the missing element
   Description:    An expected element is missing.

   error-tag:      bad-element
   error-type:     protocol, application
   error-severity: error
   error-info:     <bad-element> : name of the element w/ bad value
   Description:    An element value is not correct; e.g., wrong type,
                   out of range, pattern mismatch.

   error-tag:      unknown-element
   error-type:     protocol, application
   error-severity: error
   error-info:     <bad-element> : name of the unexpected element
   Description:    An unexpected element is present.

   error-tag:      unknown-namespace
   error-type:     protocol, application
   error-severity: error
   error-info:     <bad-element> : name of the element that contains
                     the unexpected namespace
                   <bad-namespace> : name of the unexpected namespace
   Description:    An unexpected namespace is present.

   error-tag:      access-denied
   error-type:     protocol, application
   error-severity: error
   error-info:     none
   Description:    Access to the requested protocol operation or
                   data model is denied because authorization failed.
   error-tag:      lock-denied
   error-type:     protocol
   error-severity: error
   error-info:     <session-id> : session ID of session holding the
                     requested lock, or zero to indicate a non-NETCONF
                     entity holds the lock
   Description:    Access to the requested lock is denied because the
                   lock is currently held by another entity.

   error-tag:      resource-denied
   error-type:     transport, rpc, protocol, application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because of
                   insufficient resources.

   error-tag:      rollback-failed
   error-type:     protocol, application
   error-severity: error
   error-info:     none
   Description:    Request to roll back some configuration change (via
                   rollback-on-error or <discard-changes> operations)
                   was not completed for some reason.

   error-tag:      data-exists
   error-type:     application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because the relevant
                   data model content already exists.  For example,
                   a "create" operation was attempted on data that
                   already exists.

   error-tag:      data-missing
   error-type:     application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because the relevant
                   data model content does not exist.  For example,
                   a "delete" operation was attempted on
                   data that does not exist.

   error-tag:      operation-not-supported
   error-type:     protocol, application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because the requested
                   operation is not supported by this implementation.
   error-tag:      operation-failed
   error-type:     rpc, protocol, application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because the requested
                   operation failed for some reason not covered by
                   any other error condition.

   error-tag:      partial-operation
   error-type:     application
   error-severity: error
   error-info:     <ok-element> : identifies an element in the data
                     model for which the requested operation has been
                     completed for that node and all its child nodes.
                     This element can appear zero or more times in the
                     <error-info> container.

                   <err-element> : identifies an element in the data
                     model for which the requested operation has failed
                     for that node and all its child nodes.
                     This element can appear zero or more times in the
                     <error-info> container.

                   <noop-element> : identifies an element in the data
                     model for which the requested operation was not
                     attempted for that node and all its child nodes.
                     This element can appear zero or more times in the
                     <error-info> container.

   Description:    This error-tag is obsolete, and SHOULD NOT be sent
                   by servers conforming to this document.

                   Some part of the requested operation failed or was
                   not attempted for some reason.  Full cleanup has
                   not been performed (e.g., rollback not supported)
                   by the server.  The error-info container is used
                   to identify which portions of the application
                   data model content for which the requested operation
                   has succeeded (<ok-element>), failed (<bad-element>),
                   or not been attempted (<noop-element>).
   error-tag:      malformed-message
   error-type:     rpc
   error-severity: error
   error-info:     none
   Description:    A message could not be handled because it failed to
                   be parsed correctly.  For example, the message is not
                   well-formed XML or it uses an invalid character set.

                   This error-tag is new in :base:1.1 and MUST NOT be
                   sent to old clients.

Приложение B. Схема XML для уровня сообщений NETCONF

Это приложение является нормативным.

   <CODE BEGINS> file "netconf.xsd"

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
              xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
              targetNamespace="urn:ietf:params:xml:ns:netconf:base:1.0"
              elementFormDefault="qualified"
              attributeFormDefault="unqualified"
              xml:lang="en"
              version="1.1">

     <xs:annotation>
       <xs:documentation>
         This schema defines the syntax for the NETCONF Messages layer
         messages 'hello', 'rpc', and 'rpc-reply'.
       </xs:documentation>
     </xs:annotation>

     <!--
        импорт стандартных определений XML
       -->
     <xs:import namespace="http://www.w3.org/XML/1998/namespace"
                schemaLocation="http://www.w3.org/2001/xml.xsd">
       <xs:annotation>
         <xs:documentation>
           This import accesses the xml: attribute groups for the
           xml:lang as declared on the error-message element.
         </xs:documentation>
       </xs:annotation>
     </xs:import>
     <!--
        Атрибут message-id
       -->
     <xs:simpleType name="messageIdType">
       <xs:restriction base="xs:string">
         <xs:maxLength value="4095"/>
       </xs:restriction>
     </xs:simpleType>
     <!--
        Типы, используемые для session-id
       -->
     <xs:simpleType name="SessionId">
       <xs:restriction base="xs:unsignedInt">
         <xs:minInclusive value="1"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:simpleType name="SessionIdOrZero">
       <xs:restriction base="xs:unsignedInt"/>
     </xs:simpleType>
     <!--
        Элемент <rpc>
       -->
     <xs:complexType name="rpcType">
       <xs:sequence>
         <xs:element ref="rpcOperation"/>
       </xs:sequence>
       <xs:attribute name="message-id" type="messageIdType"
                     use="required"/>
       <!--
          С элементом <rpc> могут представляться произвольные атрибуты.
         -->
       <xs:anyAttribute processContents="lax"/>
     </xs:complexType>
     <xs:element name="rpc" type="rpcType"/>
     <!--
        Типы данные и элементы, используемые для создания rpc-error
       -->
     <xs:simpleType name="ErrorType">
       <xs:restriction base="xs:string">
         <xs:enumeration value="transport"/>
         <xs:enumeration value="rpc"/>
         <xs:enumeration value="protocol"/>
         <xs:enumeration value="application"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:simpleType name="ErrorTag">
       <xs:restriction base="xs:string">
         <xs:enumeration value="in-use"/>
         <xs:enumeration value="invalid-value"/>
         <xs:enumeration value="too-big"/>
         <xs:enumeration value="missing-attribute"/>
         <xs:enumeration value="bad-attribute"/>
         <xs:enumeration value="unknown-attribute"/>
         <xs:enumeration value="missing-element"/>
         <xs:enumeration value="bad-element"/>
         <xs:enumeration value="unknown-element"/>
         <xs:enumeration value="unknown-namespace"/>
         <xs:enumeration value="access-denied"/>
         <xs:enumeration value="lock-denied"/>
         <xs:enumeration value="resource-denied"/>
         <xs:enumeration value="rollback-failed"/>
         <xs:enumeration value="data-exists"/>
         <xs:enumeration value="data-missing"/>
         <xs:enumeration value="operation-not-supported"/>
         <xs:enumeration value="operation-failed"/>
         <xs:enumeration value="partial-operation"/>
         <xs:enumeration value="malformed-message"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:simpleType name="ErrorSeverity">
       <xs:restriction base="xs:string">
         <xs:enumeration value="error"/>
         <xs:enumeration value="warning"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:complexType name="errorInfoType">
       <xs:sequence>
         <xs:choice>
           <xs:element name="session-id" type="SessionIdOrZero"/>
           <xs:sequence minOccurs="0" maxOccurs="unbounded">
             <xs:sequence>
               <xs:element name="bad-attribute" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="bad-element" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="ok-element" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="err-element" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="noop-element" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="bad-namespace" type="xs:string"
                           minOccurs="0" maxOccurs="1"/>
             </xs:sequence>
           </xs:sequence>
         </xs:choice>
         <!-- Элементы из любого другого пространства имен также могут
              следовать за элементами NETCONF -->
         <xs:any namespace="##other" processContents="lax"
                 minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>
     <xs:complexType name="rpcErrorType">
       <xs:sequence>
         <xs:element name="error-type" type="ErrorType"/>
         <xs:element name="error-tag" type="ErrorTag"/>
         <xs:element name="error-severity" type="ErrorSeverity"/>
         <xs:element name="error-app-tag" type="xs:string"
                     minOccurs="0"/>
         <xs:element name="error-path" type="xs:string" minOccurs="0"/>
         <xs:element name="error-message" minOccurs="0">
           <xs:complexType>
             <xs:simpleContent>
               <xs:extension base="xs:string">
                 <xs:attribute ref="xml:lang" use="optional"/>
               </xs:extension>
             </xs:simpleContent>
           </xs:complexType>
         </xs:element>
         <xs:element name="error-info" type="errorInfoType"
                     minOccurs="0"/>
       </xs:sequence>
     </xs:complexType>
     <!--
        Атрибуты операции, используемые в <edit-config>
       -->
     <xs:simpleType name="editOperationType">
       <xs:restriction base="xs:string">
         <xs:enumeration value="merge"/>
         <xs:enumeration value="replace"/>
         <xs:enumeration value="create"/>
         <xs:enumeration value="delete"/>
         <xs:enumeration value="remove"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:attribute name="operation" type="editOperationType"/>
     <!--
        Элемент <rpc-reply>
       -->
     <xs:complexType name="rpcReplyType">
       <xs:choice>
         <xs:element name="ok"/>
         <xs:sequence>
           <xs:element ref="rpc-error"
                       minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="rpcResponse"
                       minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
       </xs:choice>
       <xs:attribute name="message-id" type="messageIdType"
                     use="optional"/>
       <!--
          Любые атрибуты, представленные с элементом <rpc>, должны возвращаться
          с <rpc-reply>.
         -->
       <xs:anyAttribute processContents="lax"/>
     </xs:complexType>
     <xs:element name="rpc-reply" type="rpcReplyType"/>
     <!--
        Элемент <rpc-error>
          -->
     <xs:element name="rpc-error" type="rpcErrorType"/>
     <!--
        rpcOperationType используется в качестве базового типа
        для всех операций NETCONF 
       -->
     <xs:complexType name="rpcOperationType"/>
     <xs:element name="rpcOperation" type="rpcOperationType"
                 abstract="true"/>
     <!--
        rpcResponseType используется в качестве базового типа
        для всех откликов NETCONF
       -->
     <xs:complexType name="rpcResponseType"/>
     <xs:element name="rpcResponse" type="rpcResponseType"
                 abstract="true"/>
     <!--
        Элемент <hello>
       -->
     <xs:element name="hello">
       <xs:complexType>
         <xs:sequence>
           <xs:element name="capabilities">
             <xs:complexType>
               <xs:sequence>
                 <xs:element name="capability" type="xs:anyURI"
                             maxOccurs="unbounded"/>
               </xs:sequence>
             </xs:complexType>
           </xs:element>
           <xs:element name="session-id" type="SessionId"
                       minOccurs="0"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>
   </xs:schema>

   <CODE ENDS>

Приложение C. Модуль YANG для операций протокола NETCONF

Это приложение является нормативным.

Модуль YANG ietf-netconf импортирует определения типов (typedef) из [RFC6021].

  <CODE BEGINS> file "ietf-netconf@2011-06-01.yang"

  module ietf-netconf {

    // Пространство имен для определений NETCONF XML не изменилось 
    // по сравнению RFC 4741, который этот документ заменяет
    namespace "urn:ietf:params:xml:ns:netconf:base:1.0";

    prefix nc;

    import ietf-inet-types {
      prefix inet;
    }

    organization
      "IETF NETCONF (Network Configuration) Working Group";

    contact
      "WG Web:   <http://tools.ietf.org/wg/netconf/>
       WG List:  <netconf@ietf.org>

       WG Chair: Bert Wijnen
                 <bertietf@bwijnen.net>

       WG Chair: Mehmet Ersue
                 <mehmet.ersue@nsn.com>

       Editor:   Martin Bjorklund
                 <mbj@tail-f.com>

       Editor:   Juergen Schoenwaelder
                 <j.schoenwaelder@jacobs-university.de>

       Editor:   Andy Bierman
                 <andy.bierman@brocade.com>";

    description
      "NETCONF Protocol Data Types and Protocol Operations.

       Copyright (c) 2011 IETF Trust and the persons identified as
       the document authors.  All rights reserved.

       Redistribution and use in source and binary forms, with or
       without modification, is permitted pursuant to, and subject
       to the license terms contained in, the Simplified BSD License
       set forth in Section 4.c of the IETF Trust's Legal Provisions
       Relating to IETF Documents
       (http://trustee.ietf.org/license-info).

       This version of this YANG module is part of RFC 6241; see
       the RFC itself for full legal notices.";
    revision 2011-06-01 {
      description
        "Initial revision";
      reference
        "RFC 6241: Network Configuration Protocol";
    }

    extension get-filter-element-attributes {
      description
        "If this extension is present within an 'anyxml'
         statement named 'filter', which must be conceptually
         defined within the RPC input section for the <get>
         and <get-config> protocol operations, then the
         following unqualified XML attribute is supported
         within the <filter> element, within a <get> or
         <get-config> protocol operation:

           type : optional attribute with allowed
                  value strings 'subtree' and 'xpath'.
                  If missing, the default value is 'subtree'.

         If the 'xpath' feature is supported, then the
         following unqualified XML attribute is
         also supported:

           select: optional attribute containing a
                   string representing an XPath expression.
                   The 'type' attribute must be equal to 'xpath'
                   if this attribute is present.";
    }

    // Возможности NETCONF, определенные как функции
    feature writable-running {
      description
        "NETCONF :writable-running capability;
         If the server advertises the :writable-running
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.2";
    }

    feature candidate {
      description
        "NETCONF :candidate capability;
         If the server advertises the :candidate
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.3";
    }

    feature confirmed-commit {
      if-feature candidate;
      description
        "NETCONF :confirmed-commit:1.1 capability;
         If the server advertises the :confirmed-commit:1.1
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";

      reference "RFC 6241, Section 8.4";
    }

    feature rollback-on-error {
      description
        "NETCONF :rollback-on-error capability;
         If the server advertises the :rollback-on-error
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.5";
    }

    feature validate {
      description
        "NETCONF :validate:1.1 capability;
         If the server advertises the :validate:1.1
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.6";
    }

    feature startup {
      description
        "NETCONF :startup capability;
         If the server advertises the :startup
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.7";
    }

    feature url {
      description
        "NETCONF :url capability;
         If the server advertises the :url
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.8";
    }

    feature xpath {
      description
        "NETCONF :xpath capability;
         If the server advertises the :xpath
         capability for a session, then this feature must
         also be enabled for that session.  Otherwise,
         this feature must not be enabled.";
      reference "RFC 6241, Section 8.9";
    }

    // Простые типы NETCONF

    typedef session-id-type {
      type uint32 {
        range "1..max";
      }
      description
        "NETCONF Session Id";
    }

    typedef session-id-or-zero-type {
      type uint32;
      description
        "NETCONF Session Id or Zero to indicate none";
    }
    typedef error-tag-type {
      type enumeration {
         enum in-use {
           description
             "The request requires a resource that
              already is in use.";
         }
         enum invalid-value {
           description
             "The request specifies an unacceptable value for one
              or more parameters.";
         }
         enum too-big {
           description
             "The request or response (that would be generated) is
              too large for the implementation to handle.";
         }
         enum missing-attribute {
           description
             "An expected attribute is missing.";
         }
         enum bad-attribute {
           description
             "An attribute value is not correct; e.g., wrong type,
              out of range, pattern mismatch.";
         }
         enum unknown-attribute {
           description
             "An unexpected attribute is present.";
         }
         enum missing-element {
           description
             "An expected element is missing.";
         }
         enum bad-element {
           description
             "An element value is not correct; e.g., wrong type,
              out of range, pattern mismatch.";
         }
         enum unknown-element {
           description
             "An unexpected element is present.";
         }
         enum unknown-namespace {
           description
             "An unexpected namespace is present.";
         }
         enum access-denied {
           description
             "Access to the requested protocol operation or
              data model is denied because authorization failed.";
         }
         enum lock-denied {
           description
             "Access to the requested lock is denied because the
              lock is currently held by another entity.";
         }
         enum resource-denied {
           description
             "Request could not be completed because of
              insufficient resources.";
         }
         enum rollback-failed {
           description
             "Request to roll back some configuration change (via
              rollback-on-error or <discard-changes> operations)
              was not completed for some reason.";

         }
         enum data-exists {
           description
             "Request could not be completed because the relevant
              data model content already exists.  For example,
              a 'create' operation was attempted on data that
              already exists.";
         }
         enum data-missing {
           description
             "Request could not be completed because the relevant
              data model content does not exist.  For example,
              a 'delete' operation was attempted on
              data that does not exist.";
         }
         enum operation-not-supported {
           description
             "Request could not be completed because the requested
              operation is not supported by this implementation.";
         }
         enum operation-failed {
           description
             "Request could not be completed because the requested
              operation failed for some reason not covered by
              any other error condition.";
         }
         enum partial-operation {
           description
             "This error-tag is obsolete, and SHOULD NOT be sent
              by servers conforming to this document.";
         }
         enum malformed-message {
           description
             "A message could not be handled because it failed to
              be parsed correctly.  For example, the message is not
              well-formed XML or it uses an invalid character set.";
         }
       }
       description "NETCONF Error Tag";
       reference "RFC 6241, Appendix A";
    }

    typedef error-severity-type {
      type enumeration {
        enum error {
          description "Error severity";
        }
        enum warning {
          description "Warning severity";
        }
      }
      description "NETCONF Error Severity";
      reference "RFC 6241, Section 4.3";
    }

    typedef edit-operation-type {
      type enumeration {
        enum merge {
          description
            "The configuration data identified by the
             element containing this attribute is merged
             with the configuration at the corresponding
             level in the configuration datastore identified
             by the target parameter.";
        }
        enum replace {
          description
            "The configuration data identified by the element
             containing this attribute replaces any related
             configuration in the configuration datastore
             identified by the target parameter.  If no such
             configuration data exists in the configuration
             datastore, it is created.  Unlike a
             <copy-config> operation, which replaces the
             entire target configuration, only the configuration
             actually present in the config parameter is affected.";
        }
        enum create {
          description
            "The configuration data identified by the element
             containing this attribute is added to the
             configuration if and only if the configuration
             data does not already exist in the configuration
             datastore.  If the configuration data exists, an
             <rpc-error> element is returned with an
             <error-tag> value of 'data-exists'.";
        }
        enum delete {
          description
            "The configuration data identified by the element
             containing this attribute is deleted from the
             configuration if and only if the configuration
             data currently exists in the configuration
             datastore.  If the configuration data does not
             exist, an <rpc-error> element is returned with
             an <error-tag> value of 'data-missing'.";
        }
        enum remove {
          description
            "The configuration data identified by the element
             containing this attribute is deleted from the
             configuration if the configuration
             data currently exists in the configuration
             datastore.  If the configuration data does not
             exist, the 'remove' operation is silently ignored
             by the server.";
        }
      }
      default "merge";
      description "NETCONF 'operation' attribute values";
      reference "RFC 6241, Section 7.2";
    }

    // Стандартные протокольные операции NETCONF

    rpc get-config {
      description
        "Retrieve all or part of a specified configuration.";

      reference "RFC 6241, Section 7.1";

      input {
        container source {
          description
            "Particular configuration to retrieve.";

          choice config-source {
            mandatory true;
            description
              "The configuration to retrieve.";
            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config source.";
            }
            leaf running {
              type empty;
              description
                "The running configuration is the config source.";
            }
            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config source.
                 This is optional-to-implement on the server because
                 not all servers will support filtering for this
                 datastore.";
            }
          }
        }

        anyxml filter {
          description
            "Subtree or XPath filter to use.";
          nc:get-filter-element-attributes;
        }
      }

      output {
        anyxml data {
          description
            "Copy of the source datastore subset that matched
             the filter criteria (if any).  An empty data container
             indicates that the request did not produce any results.";
        }
      }
    }

    rpc edit-config {
      description
        "The <edit-config> operation loads all or part of a specified
         configuration to the specified target configuration.";

      reference "RFC 6241, Section 7.2";

      input {
        container target {
          description
            "Particular configuration to edit.";

          choice config-target {
            mandatory true;
            description
              "The configuration target.";

            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config target.";
            }
            leaf running {
              if-feature writable-running;
              type empty;
              description
                "The running configuration is the config source.";
            }
          }
        }

        leaf default-operation {
          type enumeration {
            enum merge {
              description
                "The default operation is merge.";
            }
            enum replace {
              description
                "The default operation is replace.";
            }
            enum none {
              description
                "There is no default operation.";
            }
          }
          default "merge";
          description
            "The default operation to use.";
        }

        leaf test-option {
          if-feature validate;
          type enumeration {
            enum test-then-set {
              description
                "The server will test and then set if no errors.";
            }
            enum set {
              description
                "The server will set without a test first.";
            }
            enum test-only {
              description
                "The server will only test and not set, even
                 if there are no errors.";
            }
          }
          default "test-then-set";
          description
            "The test option to use.";
        }

        leaf error-option {
          type enumeration {
            enum stop-on-error {
              description
                "The server will stop on errors.";
            }
            enum continue-on-error {
              description
                "The server may continue on errors.";
            }
            enum rollback-on-error {
              description
                "The server will roll back on errors.
                 This value can only be used if the 'rollback-on-error'
                 feature is supported.";
            }
          }
          default "stop-on-error";
          description
            "The error option to use.";
        }

        choice edit-content {
          mandatory true;
          description
            "The content for the edit operation.";

          anyxml config {
            description
              "Inline Config content.";
          }
          leaf url {
            if-feature url;
            type inet:uri;
            description
              "URL-based config content.";
          }
        }
      }
    }

    rpc copy-config {
      description
        "Create or replace an entire configuration datastore with the
         contents of another complete configuration datastore.";

      reference "RFC 6241, Section 7.3";

      input {
        container target {
          description
            "Particular configuration to copy to.";

          choice config-target {
            mandatory true;
            description
              "The configuration target of the copy operation.";

            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config target.";
            }
            leaf running {
              if-feature writable-running;
              type empty;
              description
                "The running configuration is the config target.
                 This is optional-to-implement on the server.";
            }
            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config target.";
            }
            leaf url {
              if-feature url;
              type inet:uri;
              description
                "The URL-based configuration is the config target.";
            }
          }
        }

        container source {
          description
            "Particular configuration to copy from.";

          choice config-source {
            mandatory true;
            description
              "The configuration source for the copy operation.";

            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config source.";
            }
            leaf running {
              type empty;
              description
                "The running configuration is the config source.";
            }
            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config source.";
            }
            leaf url {
              if-feature url;
              type inet:uri;
              description
                "The URL-based configuration is the config source.";
            }
            anyxml config {
              description
                "Inline Config content: <config> element.  Represents
                 an entire configuration datastore, not
                 a subset of the running datastore.";
            }
          }
        }
      }
    }

    rpc delete-config {
      description
        "Delete a configuration datastore.";

      reference "RFC 6241, Section 7.4";

      input {
        container target {
          description
            "Particular configuration to delete.";

          choice config-target {
            mandatory true;
            description
              "The configuration target to delete.";

            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config target.";
            }
            leaf url {
              if-feature url;
              type inet:uri;
              description
                "The URL-based configuration is the config target.";
            }
          }
        }
      }
    }

    rpc lock {
      description
        "The lock operation allows the client to lock the configuration
         system of a device.";
      reference "RFC 6241, Section 7.5";

      input {
        container target {
          description
            "Particular configuration to lock.";

          choice config-target {
            mandatory true;
            description
              "The configuration target to lock.";

            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config target.";
            }
            leaf running {
              type empty;
              description
                "The running configuration is the config target.";
            }
            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config target.";
            }
          }
        }
      }
    }

    rpc unlock {
      description
        "The unlock operation is used to release a configuration lock,
         previously obtained with the 'lock' operation.";

      reference "RFC 6241, Section 7.6";

      input {
        container target {
          description
            "Particular configuration to unlock.";

          choice config-target {
            mandatory true;
            description
              "The configuration target to unlock.";

            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config target.";
            }
            leaf running {
              type empty;
              description
                "The running configuration is the config target.";
            }
            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config target.";
            }
          }
        }
      }
    }

    rpc get {
      description
        "Retrieve running configuration and device state information.";

      reference "RFC 6241, Section 7.7";

      input {
        anyxml filter {
          description
            "This parameter specifies the portion of the system
             configuration and state data to retrieve.";
          nc:get-filter-element-attributes;
        }
      }

      output {
        anyxml data {
          description
            "Copy of the running datastore subset and/or state
             data that matched the filter criteria (if any).
             An empty data container indicates that the request did not
             produce any results.";
        }
      }
    }

    rpc close-session {
      description
        "Request graceful termination of a NETCONF session.";

      reference "RFC 6241, Section 7.8";
    }

    rpc kill-session {
      description
        "Force the termination of a NETCONF session.";

      reference "RFC 6241, Section 7.9";

      input {
        leaf session-id {
          type session-id-type;
          mandatory true;
          description
            "Particular session to kill.";
        }
      }
    }

    rpc commit {
      if-feature candidate;

      description
        "Commit the candidate configuration as the device's new
         current configuration.";

      reference "RFC 6241, Section 8.3.4.1";

      input {
        leaf confirmed {
          if-feature confirmed-commit;
          type empty;
          description
            "Requests a confirmed commit.";
          reference "RFC 6241, Section 8.3.4.1";
        }

        leaf confirm-timeout {
          if-feature confirmed-commit;
          type uint32 {
            range "1..max";
          }
          units "seconds";
          default "600";   // 10 минут
          description
            "The timeout interval for a confirmed commit.";
          reference "RFC 6241, Section 8.3.4.1";
        }

        leaf persist {
          if-feature confirmed-commit;
          type string;
          description
            "This parameter is used to make a confirmed commit
             persistent.  A persistent confirmed commit is not aborted
             if the NETCONF session terminates.  The only way to abort
             a persistent confirmed commit is to let the timer expire,
             or to use the <cancel-commit> operation.

             The value of this parameter is a token that must be given
             in the 'persist-id' parameter of <commit> or
             <cancel-commit> operations in order to confirm or cancel
             the persistent confirmed commit.

             The token should be a random string.";
          reference "RFC 6241, Section 8.3.4.1";
        }

        leaf persist-id {
          if-feature confirmed-commit;
          type string;
          description
            "This parameter is given in order to commit a persistent
             confirmed commit.  The value must be equal to the value
             given in the 'persist' parameter to the <commit> operation.
             If it does not match, the operation fails with an
            'invalid-value' error.";
          reference "RFC 6241, Section 8.3.4.1";
        }
      }
    }

    rpc discard-changes {
      if-feature candidate;

      description
        "Revert the candidate configuration to the current
         running configuration.";
      reference "RFC 6241, Section 8.3.4.2";
    }

    rpc cancel-commit {
      if-feature confirmed-commit;
      description
        "This operation is used to cancel an ongoing confirmed commit.
         If the confirmed commit is persistent, the parameter
         'persist-id' must be given, and it must match the value of the
         'persist' parameter.";
      reference "RFC 6241, Section 8.4.4.1";

      input {
        leaf persist-id {
          type string;
          description
            "This parameter is given in order to cancel a persistent
             confirmed commit.  The value must be equal to the value
             given in the 'persist' parameter to the <commit> operation.
             If it does not match, the operation fails with an
            'invalid-value' error.";
        }
      }
    }

    rpc validate {
      if-feature validate;

      description
        "Validates the contents of the specified configuration.";

      reference "RFC 6241, Section 8.6.4.1";

      input {
        container source {
          description
            "Particular configuration to validate.";

          choice config-source {
            mandatory true;
            description
              "The configuration source to validate.";

            leaf candidate {
              if-feature candidate;
              type empty;
              description
                "The candidate configuration is the config source.";
            }
            leaf running {
              type empty;
              description
                "The running configuration is the config source.";
            }
            leaf startup {
              if-feature startup;
              type empty;
              description
                "The startup configuration is the config source.";
            }
            leaf url {
              if-feature url;
              type inet:uri;
              description
                "The URL-based configuration is the config source.";
            }
            anyxml config {
              description
                "Inline Config content: <config> element.  Represents
                 an entire configuration datastore, not
                 a subset of the running datastore.";
            }
          }
        }
      }
    }
  }

  <CODE ENDS>

Приложение D. Шаблон возможности

В этот ненормативном приложении определен шаблон, который может использоваться для определения возможностей протокола. Моделям данных YANG обычно не требуется определять возможности протокола, поскольку использование YANG автоматически ведет к анонсированию модели данных и всех необязательных частей этой модели, которые в YANG называются функциями. Шаблон возможностей предназначен для использования в тех случаях, когда механизмов YANG недостаточно (например, при обработке переметризованных функций) или применяется другой язык моделирования данных.

D.1. capability-name (шаблон)

D.1.1. Overview

D.1.2. Dependencies

D.1.3. Capability Identifier

The {name} capability is identified by the following capability string:

      {capability uri}

D.1.4. New Operations

D.1.4.1. <op-name>

D.1.5. Modifications to Existing Operations

D.1.5.1. <op-name>

If existing operations are not modified by this capability, this section may be omitted.

D.1.6. Interactions with Other Capabilities

If this capability does not interact with other capabilities, this section may be omitted.

Приложение E. Настройка множества устройств в NETCONF

Это приложение не является нормативным.

E.1. Операции с отдельным устройством

Рассмотрим работу, связанную с обновлением конфигурации одного отдельно взятого устройства. Принимая изменения конфигурации приложение должно верить, что изменение выполнено корректно и не будет препятствовать работе устройства. Приложению (и его пользователю) нужна уверенность в том, что изменение не повредит сети.

Защищенная смена конфигурации каждого отдельного устройства включает множество этапов:

  • блокировка конфигурации;

  • создание контрольной точки для рабочей конфигурации;

  • загрузка и проверка пригодности новой конфигурации;

  • замена рабочей конфигурации;

  • тестирование новой конфигурации;

  • сохранение изменений (если они устраивают);

  • снятие блокировки.

Далее все эти этапы рассмотрены более подробно.

E.1.1. Блокировка конфигурации

Блокировка нужна для предотвращение одновременного обновления конфигурации из нескольких источников. При воздействии на устройство нескольких источников ему будет сложно проверить изменения и восстановить конфигурацию в случае неудачи. Краткосрочная блокировка является самой простой защитой от попыток внесений изменений с нескольких сторон.

Блокировку можно организовать с помощью операции <lock>.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <lock>
         <target>
           <running/>
         </target>
       </lock>
     </rpc>

если поддерживается возможность :candidate, конфигурацию-кандидат следует заблокировать.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <lock>
         <target>
           <candidate/>
         </target>
       </lock>
     </rpc>

E.1.2. Контрольные точки рабочей конфигурации

Рабочую конфигурацию можно сохранить в локальном файле в качестве контрольной точки перед загрузкой новой конфигурации. Если обновление будет неудачным, конфигурацию можно будет восстановить из этого файла.

Контрольную точку можно создать с помощью операции <copy-config>.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <copy-config>
         <target>
           <url>file://checkpoint.conf</url>
         </target>
         <source>
           <running/>
         </source>
       </copy-config>
     </rpc>

Для восстановления конфигурации служит та же операция со сменой мест параметров <source> и <target>.

E.1.3. Загрузка и проверка пригодности конфигурации

Если поддерживается возможность :candidate, конфигурация может быть загружена в устройство без воздействия на работающую систему.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <candidate/>
         </target>
         <config>
           <!-- здесь указываются изменения конфигурации -->
         </config>
       </edit-config>
     </rpc>

Если устройство поддерживает возможность :validate:1.1, оно будет по умолчанию проверять пригодность входящей конфигурации при загрузке в хранилище-кандидат. Для отключения такой проверки служит параметр <test-option> со значением set. Полную проверку можно запросить с помощью операции <validate>.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <validate>
         <source>
           <candidate/>
         </source>
       </validate>
     </rpc>

E.1.4. Изменение рабочей конфигурации

Когда входящая конфигурация была загружена в устройство и проверена, ее можно активизировать в системе.

Если устройство поддерживает возможность :candidate, операция <commit> копирует информацию из хранилища-кандидата в рабочую конфигурацию. Параметр <confirmed> позволяет автоматически восстановить исходную конфигурацию, если связь с устройством будет потеряна.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <commit>
         <confirmed/>
         <confirm-timeout>120</confirm-timeout>
       </commit>
     </rpc>

Если конфигурация-кандидат не поддерживается устройством, входящая конфигурация загружается непосредственно в рабочее хранилище.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <!-- здесь указываются изменения конфигурации -->
         </config>
       </edit-config>
     </rpc>

E.1.5. Тестирование новой конфигурации

Когда входящая конфигурация передана в рабочую, приложению нужно убедиться в отсутствии негативного влияния на работу устроства.

Для обретения такой уверенности приложение может воспользоваться тестами рабочего состояния устройства. Природа таких тестов зависит от внесенных изменений и выходит за рамки документа. Тесты могут включать проверку доступности из системы, где работает приложение (ping), изменений в доступности остальной сети (сравнение таблиц маршрутизации) или инспектирование отдельных изменений (например, обнаружение сессии с добавленным партнером BGP).

E.1.6. Сохранение изменений

Когда изменения в конфигурацию внесены и приложение имеет достаточную уверенность в корректности работы устройства, внесенные изменения можно зафиксировать (сохранить).

Если устройство поддерживает возможность :startup, текущая конфигурация может быть сохранена путем указания стартового хранилища в качестве цели операции <copy-config>.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <copy-config>
         <target>
           <startup/>
         </target>
         <source>
           <running/>
         </source>
       </copy-config>
     </rpc>

Если устройство поддерживает возможность :candidate и было запрошено подтверждаемое представление, должно произойти подтверждающее представление конфигурации да завершения срок ожидания.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <commit/>
     </rpc>

E.1.7. Снятие блокировки конфигурации

Когда обновление конфигурации завершено, блокировка должна быть снята, чтобы другие приложения могли получить доступ к конфигурации.

Для снятия блокировки служит операция <unlock>.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <unlock>
         <target>
           <running/>
         </target>
       </unlock>
     </rpc>

Если поддерживается возможность :candidate, следует разблокировать конфигурацию-кандидат.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <unlock>
         <target>
           <candidate/>
         </target>
       </unlock>
     </rpc>

E.2. Операции со множеством устройств

Когда для изменения конфигурации требуется обновление множества устройство, следует соблюдать осторожность при выборе семантики транзакций. Протокол NETCONF содержит достаточно примитивой для организации ориентированных на транзакции операций. Обеспечение полной семантики транзакций на многочисленных устройствах чрезмерно дорого, но размер и число окон для случаев отказа можно снизить.

Имеется два класса операций с множеством устройств. Первый класс разрешает отказы на одельных устройствах без возврата конфигурации остальных устройств в исходное состояние. Операция может быть повторена позднее или об отказе может быть просто сообщено пользователю. Примером такого класса операций может служить добавление сервера NTP. Для операций этого класса предотвращение отказов и восстановление сфокусировано на отдельных устройствах. Это предполагает восстановление устройства, отчет об отказе и, возможно, повторную попытку.

Второй класс более интересен и требует завершения операций на всех устройствах или полного возврата к пержней конфигурации. Т. е. сеть должна целиком перейти в новое состояние или восстановить прежнее. Например, переход на VPN может потребовать обновления множества устройств. Другим примером может служить определение нового класса обслуживания. Если в сети будет обновлена лишь часть устройств, приведет к проблемам, когда начнется применение нового класса определения.

Для обеспечения семантики транзакций выполняются те же операции, которые были описаны выше для отдельного устройства, но они происходят параллельно на всех устройствах. Блокировку конфигурации следует активизировать на всхе целевых устройствах и сохранять до тех пор, пока все устройства не будут полностью обновлены с сохранением их новой конфигурации. Изменения конфигурации следует загружать и проверять на всех устройствах. Контрольные точки также следует делать для каждого устройства. После этого рабочая конфигурация меняется, тестируется и сохраняется. Если на любом из этапов возникает отказ, конфигурация может быть восстановлена на любом устройстве, где она была изменена. После полной реализации (или полного отказа) блокировку можно снять на всех устройствах.

Приложение F. Отличия от RFC 4741

В это приложении отмечены основные отличия данного документа от RFC 4741.

  • Добавлен тег ошибки malformed-message.

  • Добавлено перечисляемое значение remove для атрибута operation.

  • Отменен тег ошибки partial-operation.

  • Добавлены параметры <persist> и <persist-id> для операции <commit>.

  • Обновлен идентификатор URI базового протокола и уточнен обмен сообщениями <hello> для выбора и идентификации версии базового протокола, используемого в конкретной сессии.

  • Добавлен модуль YANG для моделирования операций и удален уровень операций из XSD.

  • Уточнено поведение блокировки для хранилища-кандидата.

  • Уточнены требования к откликам сервера на ошибки для значения delete в атрибуте operation.

  • Добавлен мезанизм шаблонов пространства имен для фильтрации ветевый (subtree).

  • Добавлено значение test-only для параметра <test-option> операции <edit-config>.

  • Добавлена операция <cancel-commit>.

  • Введено имя пользователя NETCONF и требования для транспортных протоколов, разъясняющие вывод имени пользователя.


Адреса авторов

Rob Enns (редактор)

Juniper Networks

EMail: rob.enns@gmail.com

Martin Bjorklund (редактор)

Tail-f Systems

EMail: mbj@tail-f.com

Juergen Schoenwaelder (редактор)

Jacobs University

EMail: j.schoenwaelder@jacobs-university.de

Andy Bierman (редактор)

Brocade

EMail: andy.bierman@brocade.com


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1Blocks Extensible Exchange Protocol — расширяемый протокол обмен блоками.

2Authentication, Authorization, and Accounting — проверка подлинности, контроль полномочий и учет.

3В RFC 7950 определена спецификация версии 1.1 протокола YANG, однако новый документ не отменяет RFC 6020. Прим. перев.

4Этот документ был обновлен. На момент публикации перевода новый вариант был доступен по ссылке. Прим. перев.




RFC 6241 Network Configuration Protocol (NETCONF)

Internet Engineering Task Force (IETF)                      R. Enns, Ed.
Request for Comments: 6241                              Juniper Networks
Obsoletes: 4741                                        M. Bjorklund, Ed.
Category: Standards Track                                 Tail-f Systems
ISSN: 2070-1721                                    J. Schoenwaelder, Ed.
                                                       Jacobs University
                                                         A. Bierman, Ed.
                                                                 Brocade
                                                               June 2011

Протокол настройки сети (NETCONF)

Network Configuration Protocol (NETCONF)

PDF

Тезисы

Протокол настройки сети (NETCONF1), определенный в этом документе, обеспечивает механизмы установки, изменения и удаления конфигурационных параметров сетевых устройств. Он использует представление данных на основе расширяемого языка разметки (XML2) для параметров конфигурации и протокольных сообщений. Работа протокола NETCONF основана на удаленных вызовах процедур (RPC3). Данный документ служит заменой RFC 4741.

Статус документа

Этот документ содержит проект стандарта Internet (Internet Standards Track).

Документ является результатом работы IETF4 и представляет согласованное мнение сообщества IETF. Документ был вынесен на открытое обсуждение и одобрен для публикации IESG5. Дополнительная информация о стандартах Internet приведена в разделе 2 документа RFC 5741.

Информация о статусе этого документа, обнаруженных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc6241.

Авторские права

Авторские права (c) 2011 принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменен вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

Оглавление

Исключено в версии HTML.

1. Введение

Протокол NETCONF определяет простой механизм, обеспечивающий возможность настройки сетевых устройств и получения от них параметров конфигурации. Протокол позволяет устройству представлять (показывать) полностью формальный интерфейс API6. Приложения могут использовать этот простой API для отправки и получения полного или частичного набора данных конфигурации устройства.

Протокол NETCONF использует парадигму удаленного вызова процедур (RPC). Клиент кодирует RPC в формат XML [W3C.REC-xml-20001006] и передает его серверу через защищенную, ориентированную на соединения сессию Сервер возвращает отклик в формате XML. Содержимое запросов и откликов полностью описывается в XML DTD или схемах XML, позволяя сторонам учитывать синтаксические ограничения при обмене.

Основной особенностью протокола NETCONF является то, что функциональность протокола управления весьма точно отражает функциональность самого устройства. Это снижает расходы на реализацию и обеспечивает своевременный доступ к новым возможностям. Кроме того, приложения могут получать доступ к семантическому и синтаксическому содержимому естественного интерфейса управления устройством.

NETCONF позволяет клиенту определить набор протокольных расширений, поддерживаемых сервером. Благодаря этому, клиент может настроить свое поведение так, чтобы в полной мере использовать представленные устройством возможности. Определения возможностей могут легко расширяться без централизованного управления. Стандартные и нестандартные могут быть определены с семантической и синтаксической строгостью. Воззможности рассматриваются в разделе 8.

Протокол NETCONF является одним из блоков для построения автоматизированных систем настройки конфигурации. XML — это язык обмена информацией, обеспечивающий гибкий, но четко определенный механизм представления иерархического содержимого. Протокол NETCONF может использоваться вместе с технологиями преобразования на основе XML типа XSLT [W3C.REC-xslt-19991116] для создания систем автоматической генерации полных или частичных наборов данных конфигурации. Система может запрашивать в одной или нескольких базах данных информацию о топологии сети, каналах, правилах, пользователях и службах. Эти данные могут преобразовываться с помощью одного или множества сценариев XSLT из нацеленных на задачи и независимых от производителя схем данных в формы для конкретного производителя, продукции, операционной системы и версии программ. Полученные в результате данные могут быть переданы устройству по протоколу NETCONF.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

1.1. Терминология

candidate configuration datastore — дополнительное хранилище конфигурации (кандидат)

Конфигурационное хранилище, содержимое которого можно изменять без влияния на текущую конфигурацию устройства и впоследствии передать в рабочее хранилище. Такую возможность поддерживают не все устройства.

capability — дополнительная возможность

Функциональность, дополняющая базовую спецификацию NETCONF.

client — клиент

Инициирует (вызывает) протокольные операции на сервере. В дополнение к этому клиент может получать от сервера уведомления.

configuration data — данные конфигурации

Набор данных, в которые возможна запись, для перевода системы из ее начального состояния в текущее состояние конфигурации.

datastore — хранилище

Концептуальное место хранения информации и доступа к ней. Хранилище может быть реализовано с использованием файлов, баз данных, флэш-памяти или их комбинации.

configuration datastore — хранилище конфигурации

Хранилище данных, содержащее полный набор параметров конфигурации, требуемых для перевода устройства из начального состояния в желаемое рабочее состояние.

message — сообщение

Протокольный объект, передаваемый через соединение. Сообщения используют формат XML.

notification — уведомления

Инициированное сервером сообщение о неком событии на сервере.

protocol operation — протокольная операция

Вызов указанной удаленной процедуры при использовании в протоколе NETCONF.

remote procedure call (RPC) — вызов удаленно процедуры

Реализуется путем обмена сообщениями <rpc> и <rpc-reply>.

running configuration datastore — хранилище рабочей конфигурации

Конфигурационное хранилище, содержащее конфигурацию, которая в настоящее время используется устройством. Рабочее хранилище существует всегда.

server — сервер

Выполняет протокольные операции, инициированные клиентом. Кроме того, сервер может передавать клиенту уведомления.

session — сессия

Клиент и сервер обмениваются сообщениями, используя защищенную, ориентированную на соединения сессию.

startup configuration datastore — хранилище стартовой конфигурации

Конфигурационное хранилище, содержащее информацию, которую устройство использует при загрузке (включении). Присутствует только на устройствах с раздельными хранилищами для стартовой и рабочей конфигурации.

state data — данные состояния

Дополнительные данные системы, которые не относятся к параметрам конфигурации (например, предназначенные только для чтения данные о состоянии и собранной статистике).

user — пользователь

Подтвердивший свою подлинность клиент, который обычно идентифицируется именем пользователя NETCONF.

1.2. Обзор протокола

NETCONF использует простой механизм на основе RPC для организации взаимодействия между клиентом и сервером. Клиент может быть сценарием (script) или приложением и обычно является частью системы управления сетью. Сервером обычно выступает сетевое устройство. Термины «устройство» и «сервер» в этом документе имеют общее значение, равно как термины «клиент» и «приложение».

Сессия NETCONF представляет собой логическое соединение между сетевым администратором или приложениям для управления сетью и сетевым устройством. Устройство должно поддерживать хотя бы одну сессию NETCONF и следует поддерживать множество сессий. Глобальные параметры конфигурации могут быть изменены в любой полномочной сессии и влияние этих изменений будет видно во всех сессиях. Сеансовые параметры оказывают влияние лишь на ту сессию, в которой они были изменены.

Протокол NETCONF можно концептуально разделить на четыре уровня, как показано на рисунке 1.

        Layer                 Example
    +-------------+      +-----------------+      +----------------+
(4) |   Content   |      |  Configuration  |      |  Notification  |
    |             |      |      data       |      |      data      |
    +-------------+      +-----------------+      +----------------+
           |                       |                      |
    +-------------+      +-----------------+              |
(3) | Operations  |      |  <edit-config>  |              |
    |             |      |                 |              |
    +-------------+      +-----------------+              |
           |                       |                      |
    +-------------+      +-----------------+      +----------------+
(2) |  Messages   |      |     <rpc>,      |      | <notification> |
    |             |      |   <rpc-reply>   |      |                |
    +-------------+      +-----------------+      +----------------+
           |                       |                      |
    +-------------+      +-----------------------------------------+
(1) |   Secure    |      |  SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... |
    |  Transport  |      |                                         |
    +-------------+      +-----------------------------------------+

Рисунок 1. Уровни протокола NETCONF.

  1. Уровень защищенного транспорта (Secure Transport) обеспечивает коммуникационный путь между клиентом и сервером. NETCONF может работать на основе любого транспортного протокола, соответствующего базовым требованиям, которые приведены в разделе 2.

  2. Уровень сообщений (Messages) обеспечивает простой и независимый от транспорта механизм кадрирования сообщений для представления RPC и уведомлений. Сообщения RPC описаны в разделе 4, а уведомления — в [RFC5717].

  3. Уровень операций (Operations) определяет набор базовых операций протокола, выполняемых методами RPC с представлением параметров в формате XML. Список базовых операций протокола приведен в разделе 7.

  4. Уровень содержимого (Content) выходит за рамки этого документа. Предполагается выполнение отдельной работы по стандартизации моделей данных NETCONF.

Язык моделирования данных YANG [RFC6020] был разработан для описания моделей данных и операций протокола NETCONF. Этот язык охватывает уровни (3) и (4) на рисунке 1.

1.3. Возможности

Возможности NETCONF (capability) представляют собой наборы функциональности, дополняющие базовую спецификацию NETCONF. Возможности указываются идентификаторами URI7 [RFC3986].

Возможности дополняют базовые операции устройства, описывая дополнительные операции и разрешенное для этих операций содержимое. Клиент может определить возможности сервера и применять дополнительные операции, параметры и содержимое, определенные для этих возможностей.

Определение возможности может ссылаться на одну или несколько возможностей, от которых данных возможность зависит. Для поддержки такой возможности сервер должен поддерживать все возможности, от которых она зависит.

В разделе 8 определен обмен информацией о возможностях, который позволяет клиенту узнать возможности сервера. В этом же разделе приведен список возможностей, определенных в этом документе.

Дополнительные возможности могут определяться в других документах и это обеспечивает постоянно расширение возможностей. Органы стандартизации могут определять стандартизованные возможности, а производители — фирменные. Идентификаторы URI для возможностей должны четко указывать орган именования для предотвращения путаницы.

1.4. Разделение данных конфигурации и состояния

Информация, которая может быть получена из работающие системы, делится на две категории — параметры конфигурации и данные состояния. Параметры конфигурации представляют собой набор данных с возможностью записи, которые обеспечивают переход системы из начального состояния в рабочее. Данные о состоянии системы не относятся к конфигурационным и обычно доступны только для чтения. Эти данные включают информацию о текущем состоянии устройства и собранную статистику. Если при настройке конфигурации системы используются данные состояния, возникают многочисленные проблемы:

  • при сравнении данных будут доминировать не имеющие отношения к настройке величины типа статистики;

  • входящая информация будет включать бессмысленные запросы типа попыток записи в поля, открытые лишь для чтения;

  • наборы данных будут велики;

  • архивные данные будут включать значения, доступные лишь для считывания, что усложнит обработку при восстановлении данных из архива.

Для решения упомянутых проблем протокол NETCONF различает конфигурации параметры и данные состояния, а также используемые для тех и других операции. Например, операция <get-config> возвращает только конфигурационные данные, а <get> — конфигурационные параметры данные состояния.

Отметим, что протокол NETCONF сосредоточен на информации, которая требуется для обеспечения желаемого рабочего состояния устройства. Включение других данных зависит от реализации протокола. Например, пользовательские файлы и базы данных протокол NETCONF не считает конфигурационными. Если же локальная база данных аутентификации пользователей сохраняется на устройстве, реализация протокола может включить в конфигурационные данные.

2. Требования к транспортному протоколу

NETCONF использует коммуникационную парадигму на основе RPC. Клиент передает одно или множество сообщений с запросами RPC, которые приводят к генерации сервером соответствующих откликов RPC.

NETCONF может работать на основе любого транспортного протокола, обеспечивающего требуемую функциональность. Он не привязан к какому-то конкретному транспорту и позволяет задавать отображения для работы по разным транспортным протоколам.

Транспортный протокол должен обеспечивать уровню протокола NETCONF индикацию типа сессии (клиент или сервер).

Ниже более подробно описаны требования NETCONF к протоколу транспортного уровня.

2.1. Ориентированная на соединения работа

Протокол NETCONF относится к ориентированным на соединения и для работы ему требуется постоянная сессия между партнерами. Соединение должно обеспечивать гарантированную доставку с сохранением порядка следования пакетов.

Кроме того, запрошенные для конкретного соединения ресурсы сервера должен автоматически освобождаться при разрыве соединения, что существенно упрощает восстановление при обрывах связи и повышает отказоустойчивость. Например, при организации соединения клиентом оно сохраняется до явного завершения или до момента, когда сервер определит, что соединение было прервано. При разрыве соединения в тот момент, когда клиент продолжает блокировать (использовать) его сервер может выполнить нужные операции по восстановлению. Операция блокировки (<lock>) подробно описана в параграфе 7.5.

2.2. Проверка подлинности, целостность и конфиденциальность

Соединения NETCONF должны обеспечивать контроль подлинности, целостность данных, их защиту и предотвращение повторного использования (replay). Эти возможности NETCONF определяются транспортным протоколом. У партнеров NETCONF предполагается подобающий уровень защиты и конфиденциальности, независимо от данной спецификации. Например, соединения могут шифроваться с использованием защиты на транспортном уровне (TLS8) [RFC5246] или SSH9 [RFC4251], в зависимости от нижележащего протокола.

Соединения NETCONF должны аутентифицироваться. Транспортный протокол отвечает за проверку подлинности (аутентификацию) клиента на сервере и сервера у клиента. Партнеры NETCONF предполагают, что аутентификационные данные надлежащим образом проверены транспортным протоколом и использованием достаточно надежных механизмов и отождествление партнера должны образом проверено.

Одной из целей NETCONF является предоставление программного интерфейса с устройством, соответствующего естественному интерфейсу управления этим устройством. Поэтому предполагается, что базовый транспортный протокол использует доступные для устройства механизмы проверки подлинности. Например, сервер NETCONF на устройстве с поддержкой протокола RADIUS [RFC2865] может применять RADIUS для аутентификации сессий NETCONF.

Процесс аутентификации должен приводить к подтверждению подлинности отождествления клиента, известного серверу. Аутентифицированное отождествление клиента обычно называют имене пользователя NETCONF. Имя пользователя является строкой символов, соответствующих Char из параграфа 2.2 [W3C.REC-xml-20001006]. Алгоритм создания имен пользователей зависит от транспортного протокола и применяемого им механизма аутентификации. Транспортный протокол должен предоставлять имя пользователя для применения на других уровнях NETCONF.

Права доступа для данного клиента, указанного именем пользователя NETCONF, являются частью конфигурации сервера NETCONF. Эти права должны соблюдаться вплоть до завершения сессии NETCONF. Детали настройки прав доступа выходят за рамки этого документа.

2.3. Обязательный транспортный протокол

Реализации NETCONF должны поддерживать отображение транспортного протокола SSH [RFC6242].

3. Вопросы XML

XML служит форматом представления для NETCONF, позволяя задавать в форме текста сложные иерархические структуры, которые можно читать, сохранять и изменять с помощью текстовых редакторов и инструментов XML.

Все сообщения NETCONF должны использовать формат XML с кодировкой UTF-8 [RFC3629]. При получении сообщения <rpc> с некорректным форматом XML или отличающейся от UTF-8 кодировкой следует передавать в ответ сообщение об ошибке malformed-message. Если такое сообщение по какой-либо причине не может быть передано, сервер должен прервать сессию.

Сообщение NETCONF может начинаться с заголовка (декларации) XML (см. параграф 2.8 в [W3C.REC-xml-20001006]).

В этом разделе рассмотрены некоторые вопросы XML, связанные с NETCONF.

3.1. Пространство имен

Все элементы протокола NETCONF определены в пространстве имен

      urn:ietf:params:xml:ns:netconf:base:1.0

Имена возможностей NETCONF должны быть идентификаторами URI [RFC3986]. Возможности NETCONF рассмотрены в разделе 8.

3.2. Декларации типа документов

Декларации типа документов (см. параграф 2.8 в [W3C.REC-xml-20001006]) недопустимо включать в содержимое NETCONF.

4. Модель RPC

Протокол NETCONF использует коммуникационную модель на основе RPC. Партнеры NETCONF применяют элементы <rpc> и <rpc-reply> для обеспечения независимого от транспортного протокола кадрирования запросов и откликов NETCONF.

Синтаксис представления XML для уровня сообщений (Messages) в RPC формально определен в схеме XML, представленной в Приложении B.

4.1. Элемент <rpc>

Элемент <rpc> служит для представления запросов NETCONF, передаваемых от клиентов к серверам.

Элемент <rpc> имеет обязательный атрибут message-id, являющийся строкой, выбранной отправителем RPC и обычно представляющей собой символьное представление монотонно возрастающих целых чисел. Получатель RPC не декодирует и не интерпретирует эту строку, лишь сохраняя ее для последующего использования в качестве атрибута message-id в своем сообщении <rpc-reply>. Отправитель должен обеспечить нормализацию значений message-id в соответствии с правилами нормализации атрибутов, определенными в [W3C.REC-xml-20001006], если хочет получать строку назад в неизменном виде. Например,

       <rpc message-id="101"
            xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
         <some-method>
           <!-- параметры метода -->
         </some-method>
       </rpc>

При наличии в элементе <rpc> дополнительных атрибутов партнер NETCONF должен возвращать эти атрибуты неизменными в элементе <rpc-reply>. Это относится ко всем атрибутам xmlns.

Имя и параметры RPC указываются в содержимом элемента <rpc>. Имя RPC является элементом, расположенным непосредственно внутри элемента <rpc>, а все параметры представляются уже внутри этого элемента.

В приведенном ниже примере вызывается метод <my-own-method>, имеющий два параметра — <my-first-parameter> со значением 14 и <another-parameter> со значением fred.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <my-own-method xmlns="http://example.net/me/my-own/1.0">
         <my-first-parameter>14</my-first-parameter>
         <another-parameter>fred</another-parameter>
       </my-own-method>
     </rpc>

В следующем примере вызывается метод <rock-the-house> с параметром <zip-code>, имеющим значение 27606-0100.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rock-the-house xmlns="http://example.net/rock/1.0">
         <zip-code>27606-0100</zip-code>
       </rock-the-house>
     </rpc>

Третий пример вызывает метод NETCONF <get> без параметров.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get/>
     </rpc>

4.2. Элемент <rpc-reply>

Сообщение <rpc-reply> передается в ответ на запрос <rpc>.

Элемент <rpc-reply> имеет обязательный атрибут message-id, который совпадает с атрибутом message-id из соответствующего запроса <rpc>.

Сервер NETCONF должен также возвращать все дополнительные атрибуты, включенные в элемент <rpc>, без изменения в своем элементе <rpc-reply>.

Данные отклика представляются одним или множеством дочерних элементов внутри элемента <rpc-reply>.

Представленный ниже элемент <rpc> вызывает метод NETCONF <get> и включает дополнительный атрибут user-id. Отметим, что атрибут user-id не относится к пространству имен NETCONF. Возвращаемый элемент <rpc-reply> включает атрибут user-id, а также все запрошенное содержимое.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:ex="http://example.net/content/1.0"
          ex:user-id="fred">
       <get/>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
          xmlns:ex="http://example.net/content/1.0"
          ex:user-id="fred">
       <data>
         <!-- содержимое отклика ... -->
       </data>
     </rpc-reply>

4.3. Элемент <rpc-error>

Элемент <rpc-error> передается в сообщениях <rpc-reply> при возникновении ошибки в процессе обработки запроса <rpc>.

Если при обработке запроса <rpc> на сервере возникает множество ошибок, в отклик <rpc-reply> может включаться более одного элемента <rpc-error>. Однако от серверов не требуется обнаружение и представление более одного элемента <rpc-error>, если запрос вызывает многочисленные ошибки. От сервера не требуется проверка ошибок в каком-либо обратном порядке. Сервер лишь должен возвратить элемент <rpc-error> при возникновении любой ошибки в процессе обработки запроса.

Серверу недопустимо возвращать информацию об ошибках, относящуюся к прикладному уровню или модели данных, в элементе <rpc-error>, если клиент не имеет соответствующих прав доступа.

Элемент <rpc-error> включает перечисленную ниже информацию.

error-type

Определяет концептуальный уровень, на котором возникла ошибка и включает одно из перечисляемых значений (enumeration):

  • transport (уровень защищенного транспорта);
  • rpc (уровень сообщений);
  • protocol (уровень операций);
  • application (уровень содержимого).

error-tag

Строка с кратким описанием ошибки. Разрешенные значения приведены в Приложении A.

error-severity

Строка, показывающая уровень важности ошибки в точки зрения устройства:

  • error (ошибка);
  • warning (предупреждение).

Отметим, что ни одно из значений <error-tag>, определенных в этом документе, не использует уровня warning, который является резервом на будущее.

error-app-tag

Строка с относящейся к модели данных или реализации информацией об ошибках (если они имеются). Этот элемент не применяется, если с конкретной ошибкой не связано подходящего кода error-tag. Если имеются теги для ошибок, связанных с моделью данных и реализацией, сразу, сервер должен использовать значение, относящееся к модели данных.

error-path

Содержит абсолютное выражение XPath [W3C.REC-xpath-19991116], указывающее элемент пути к узлу, связанный с ошибкой, указанной в конкретном элементе <rpc-error>. Этот элемент не применяется при отсутствии элемента данных или узла хранения, связанного с конкретной ошибкой.

Выражение XPath интерпретируется в описанном ниже контексте:

  • набор деклараций пространств имен в рамках элемента <rpc-error>;
  • набор привязок переменных пуст;
  • библиотекой функций является основная (core) библиотека функций.

Контекст узла зависит от связанного с ошибкой узла:

  • если с ошибкой может выть связан элемент данных (payload), контекстом узла будет узел документа с запросом rpc (т. е. элемент <rpc>);
  • в остальных случаях контекстом узла является корень всех моделей данных, т. е. узел, который имеет в качестве потомков узлы верхнего уровня всех моделей данных.

error-message

Содержит строку с описанием ошибки для представления человеку. Этот элемент не включается, если для соответствующей ошибки нет подходящего описания. В элемент следует включать атрибут xml:lang в соответствии с определением [W3C.REC-xml-20001006] и обсуждением в [RFC3470].

error-info

Содержит описание ошибки для конкретного протокола или модели данных. Этот элемент не включается, если для соответствующей ошибки нет подходящего описания. В списке Приложения A определены все обязательные значения error-info для каждой ошибки. После обязательного содержимого, диктуемого протоколом, определение модели данных может требовать включения некой информации уровня приложений в контейнер error-info. Реализация может включать дополнительные элементы для представления связанной с реализацией или расширенной информацией для отладки.

В Приложении A приведены стандартные ошибки NETCONF.

Например, ошибка возвращается, если элемент <rpc> получен без атрибута message-id. Отметим, что лишь в таких случаях узел NETCONF может опускать атрибут message-id в элементе <rpc-reply>.

     <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
       </get-config>
     </rpc>

     <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rpc-error>
         <error-type>rpc</error-type>
         <error-tag>missing-attribute</error-tag>
         <error-severity>error</error-severity>
         <error-info>
           <bad-attribute>message-id</bad-attribute>
           <bad-element>rpc</bad-element>
         </error-info>
       </rpc-error>
     </rpc-reply>

Приведенный ниже отклик <rpc-reply> иллюстрирует возврат множества элементов <rpc-error>. Отметим, что используемая в примерах модель данных применяет элемент <name> для обозначения экземпляров элемента <interface>.

     <rpc-reply message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
       xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rpc-error>
         <error-type>application</error-type>
         <error-tag>invalid-value</error-tag>
         <error-severity>error</error-severity>
         <error-path xmlns:t="http://example.com/schema/1.2/config">
           /t:top/t:interface[t:name="Ethernet0/0"]/t:mtu
         </error-path>
         <error-message xml:lang="en">
           MTU value 25000 is not within range 256..9192
         </error-message>
       </rpc-error>
       <rpc-error>
         <error-type>application</error-type>
         <error-tag>invalid-value</error-tag>
         <error-severity>error</error-severity>
         <error-path xmlns:t="http://example.com/schema/1.2/config">
           /t:top/t:interface[t:name="Ethernet1/0"]/t:address/t:name
         </error-path>
         <error-message xml:lang="en">
           Invalid IP address for interface Ethernet1/0
         </error-message>
       </rpc-error>
     </rpc-reply>

4.4. Элемент <ok>

Элемент <ok> передается в сообщениях <rpc-reply> при отсутствии ошибок в процессе выполнения запроса <rpc> и данных, возвращаемых из операции. Пример показан ниже.

     <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

4.5. Конвейер обработки

Запросы NETCONF <rpc> должны обрабатываться управляемым устройством последовательно. Дополнительные запросы <rpc> могут быть переданы до завершения обработки предшествующих. Управляемое устройство должно передавать отклики в соответствии с порядком получения запросов.

5. Модель конфигурации

Протокол NETCONF обеспечивает начальный набор операций и множество возможностей, которые могут служить для расширения базы. Партнеры NETCONF обмениваются информацией о возможностях при организации сессии, как описано в параграфе 8.1.

5.1. Хранилища конфигурации

NETCONF определяет наличие одного или нескольких хранилищ конфигурации и разрешает выполнять операции с ними. Хранилище конфигурации определяется как полный набор конфигурационных данных, которые нужны для перевода устройства из начального состояние в желаемое рабочее состояние. Конфигурационные хранилища не включают данных состояния и выполняемых команд.

Хранилище рабочей конфигурации содержит полный набор конфигурационных параметров, используемых устройством в данный момент. В устройстве всегда присутствует одно хранилище этого типа. Операции протокола NETCONF, относящиеся к этому хранилищу, используют элемент <running>.

В базовой модели присутствует только рабочее (<running>) хранилище конфигурации. Дополнительные хранилища могут определяться возможностями. Такие конфигурационные хранилища доступны лишь на устройствах, анонсирующих возможности.

Возможности из параграфов 8.3 и 8.7 определяют конфигурационные хранилища <candidate> и <startup>, соответственно.

5.2. Моделирование данных

Моделирование данных и вопросы содержимого выходят за рамки протокола NETCONF. Принимается допущение о том, что модель данных устройства известна приложению и обе стороны осведомлены о таких аспектах, как макет (схема), упаковка, закрепление, поиск, замена и управление данными, а также о любых ограничениях, накладываемых моделью данных.

NETCONF передает конфигурационные данные внутри элемента <config> для модели данных устройства. Протокол считает содержимое этого элемента непрозрачным. Устройство использует возможности для анонсирования набора реализованных в устройстве моделей данных. Определение возможности детализирует работу и ограничения, вносимые моделью данных.

Устройства и менеджеры могут поддерживать множество моделей данных, включая стандартные и фирменные.

6. Фильтрация ветвей

6.1. Обзор

Фильтрация ветвей (subtree) XML представляет собой механизм, который позволяет приложению выбрать отдельные ветви XML для включения в <rpc-reply> операции <get> или <get-config>. Предоставляется небольшой набор фильтров для включения, совпадения содержимого и выбора, который позволяет создать полезные, но тоже весьма ограниченные механизмы выбора. Серверу не нужно использовать специфическую для модели данных семантику при обработке, что обеспечивает простую и централизованную стратегию реализации.

Концептуально фильтр subtree может быть пустым или содержать ветви элементов, которые представляют критерии выбора. На каждом уровне ветви набор «братских» (sibling) узлов логически обрабатывается сервером для определения включать ли ветви и элементы пути к корню в выходной результат фильтра.

Каждый узел, указанный в фильтре subtree, представляет собой включительный (inclusive) фильтр. Только связанные узлы в базовой модели или моделях данных внутри указанного хранилища на сервере будут выбраны фильтром. Узел выбирается, если он соответствует критерию выбора и иерархии элементов, указанных в данных фильтра, за исключением того, что абсолютное имя фильтра настроено на начало с уровня ниже <filter>.

Отклики содержат лишь ветви, выбранные фильтром. Любой критерий выбора, который присутствовал в запросе, включается и в отклик. Отметим, что некоторые элементы, выраженные в фильте узлами-листьями, будут раскрыты (т. е. будут включены ветви) в выходной информации фильтра. Конкретные экземпляры данных не дублируются в отклике, если этот запрос содержит множество выражений фильтров ветвей, выбирающих одни и те же данные.

6.2. Компоненты фильтра subtree

Фильтр subtree состоит из элементов XML и их атрибутов XML. В фильтрах может применяться 5 типов компонент:

  • выбор пространства имен;

  • выражение для сопоставления атрибутов;

  • сдерживающие (containment) узлы;

  • узлы выбора;

  • узлы сопоставления содержимого.

6.2.1. Выбор пространства имен

Пространство имен счтается соответствующим (в смысле фильтрации), если связанное с конкретным узлом пространство имен XML в элементе <filter> совпадает с пространством имен базовой (underlying) модели данных. Отметим, что выбор пространства имен не может применяться сам по себе. В фильтре должен быть задан хотя бы один элемент, если в результат фильтрации будут включаться любые элементы.

Для фильтра subtree определен механизм шаблонов (wildcard) пространства имен XML. Если элемент внутри элемента <filter> не определяется пространством имен (например, xmlns=»»), сервер должен оценить (evaluate) все поддерживаемые пространства имен XML, при обработке данного узла фильтра subtree. Этот механизм шаблонов не применим к атрибутам XML.

Отметим, что значения префиксов для подходящих (qualified) пространств имен не принимаются во внимание при сравнении элементов фильтра с элементами базовой модели данных.

Например,

     <filter type="subtree">
       <top xmlns="http://example.com/schema/1.2/config"/>
     </filter>

Элемент <top> является узлом выбора и только этот элемент пространств имен http://example.com/schema/1.2/config и любых дочерних узлов (из базовой модели данных) будет включен в выход фильтра.

6.2.2. Выражение для сопоставления атрибутов

Атрибуты в фильтре subtree являются частью выражения для сопоставления атрибутов. В любом типе узла фильтрации может присутствовать любое число (подходящих или не подходящих) атрибутов XML. В дополнение к критериям выбора, обычно применяемым к этому узлу, выбранные данные должны иметь соответствующие значения для каждого атрибутоа, заданного в узле. Если элемент не определен для включения указанного атрибута, он не будет выбран в результате фильтрации.

Например,

     <filter type="subtree">
       <t:top xmlns:t="http://example.com/schema/1.2/config">
         <t:interfaces>
           <t:interface t:ifName="eth0"/>
         </t:interfaces>
       </t:top>
     </filter>

В этом примере элементы <top> и <interfaces> являются узлами сдерживания, элемент <interface> является узлом выбора, ifName является выражением для сопоставления атрибутов. Только узлы interface в пространстве имен http://example.com/schema/1.2/config, имеющие атрибут ifName со значением eth0 и находящиеся в узлах interfaces внутри узлов top, будут включены в выход фильтра.

6.2.3. Узлы сдерживания

Узлы, которые содержат дочерние элементы в фильтре subtree, называются узлами сдерживания (containment node). Каждый дочерний элемент может быть узлом любого типа, включая другой узел сдерживания. Для каждого узла сдерживания, заданного в фильтре subtree, все экземпляры модели данных, которые точно соответствуют пространствам имен, иерархии элементов и всем выражениям для сопоставления атрибутов, включаются в выход фильтра.

Например,

     <filter type="subtree">
       <top xmlns="http://example.com/schema/1.2/config">
         <users/>
       </top>
     </filter>

В этом примере элемент <top> является узлом сдерживания.

6.2.4. Узлы выбора

Пустой узел leaf (лист) в фильтре называется узлом выбора (selection node) и представляет явный выбор фильтра в базовой модели данных. Присутствие каких-либо узлов выбора в наборе братских узлов будет приводить к выбору фильтром указанной ветви или ветвей и демпфированию автоматического выбора всего набора братских узлов в базовой модели данных. Для целей фильтрации пустой узел leaf может быть заявлен либо с пустым тегом (например, <foo/>), либо с явными тегами начала и завершения (например, <foo> </foo>). Любые пробельные символы в этой форме игнорируются.

Например,

     <filter type="subtree">
       <top xmlns="http://example.com/schema/1.2/config">
         <users/>
       </top>
     </filter>

В этом примере элемент <top> является узлом сдерживания, а элемент <users> — узлом выбора. Только узлы users в пространстве имен http://example.com/schema/1.2/config, которые находятся внутри элемента <top>, являющегося корнем хранилища конфингурации, будут включены в результат фильтрации.

6.2.5. Узлы сопоставления содержимого

Лист (leaf) с простым содержимым называется узлом сопоставления содержимого (content match node). Этот узел используется для выбора некоторых или всех его братских (sibling) узлов в результат фильтра и представляет собой фильтр точного соответствия (совпадения) содержимого элемента leaf. Ниже перечислены ограничения, применяемый к узлам сопоставления содержимого.

  • Узлу сопоставления недопустимо включать вложенные элементы.

  • Множество узлов сопоставления (т. е., братских узлов) логически связывается операцией AND.

  • Фильтрация смешанного содержимого не поддерживается.

  • Фильтрация содержимого списков не поддерживается.

  • Фильтрация содержимого, включающего только пробельные символы (whitespace), не поддерживается.

  • Узел сопоставления должен включать непробельные символы. Пустой элемент (например, <foo></foo>) будет считаться узлом выбора (например, <foo/>).

  • Пробельные символы в начале и в конце игнорируются, но эти же символы внутри блока текстовых символов учитываются и не меняются.

Если содержимое всех указанных братских узлов в фильтре subtree дает результат true, узлы для выхода фильтра выбираются в соответствии с приведенными ниже условиями.

  • Каждый узел сопоставления содержимого из набора братских узлов включается в выход фильтра.

  • Если в братском наборе присутствуют узлы сдерживания (containment), они обрабатываются дальше и включаются в выходной результат фильтра при выполнении вложенных условий.

  • Если в братском наборе присутствуют узлы выбора, все эти узлы включаются в выходной результат фильтра.

  • Если какие-либо братские узлы узла выбора являются компонентами идентификатора экземпляра для концептуальной структуры данных (например, лист ключа списка), они также могут включаться в выход фильтра.

  • В остальных случаях (т. е. при отсутствии узлов сдерживания и выбора в братском наборе) все узлы, определенные на этом уровне в базовой модели данных (и их ветви, если они есть) возвращаются в выходном результате фильтра.

Если любой из братских узлов сопоставления дает результат false, дальнейшая обработка этого братского набора не выполняется и ни один из узлов братского набора (включая узлы сопоставления содержимого) не выбирается фильтром.

Например,

     <filter type="subtree">
       <top xmlns="http://example.com/schema/1.2/config">
         <users>
           <user>
             <name>fred</name>
           </user>
         </users>
       </top>
     </filter>

В этом примере узлы <users> и <user> являются сдерживающими, а <name> — узлом сопоставления содержимого. Поскольку не указаны братские узлы для <name> (и, следовательно, нет узлов сдерживания и выбора), все «братья» узла <name> возвращаются на выходе фильтра. Только узлы user в пространстве имен http://example.com/schema/1.2/config, которые соответствуют иерархии элементов и для которых элемент <name> имеет значение fred, будут включены в выходной результат фильтра.

6.3. Обработка фильтра subtree

Выход фильтра (набор выбранных узлов) изначально пуст.

Каждый фильтр subtree может содержать один или множество фрагментов модели данных, представляющих часть модели, которая будет выбрана (со всеми дочерними узлами) на выходе фильтра.

Каждый фрагмент данных субдерева сравнивается сервером с поддерживаемыми им моделями данных. Если фрагмент данных фильтра (от корня до самого внутреннего элемента, указанного в фильтре) совпадает с соответствующей частью поддерживаемой модели данных, тогда узел и все его потомки будут включены в результат фильтрации.

Сервер обрабатывает все узлы с общим предком (братский набор) совместно, начиная от корня в направлении листьев. Корневые элементы фильтра считаются входящими в один братский набор (для них предполагается общее пространство имен), хотя они и не имеют общего предка.

Для каждого братского набора сервер определяет узлы для включения (или возможного включения) в результат и братские субдеревья для исключения из результат фильтрации. Сначала сервер определяет типы присутствующих в братском наборе узлов и обрабатывает эти узлы в соответствии с правилами для их типа. Если какие-то узлы из братского набора выбраны, процесс рекурсивно применяется к братским наборам каждого выбранного узла. Алгоритм продолжается, пока не будут обработаны братские наборы во всех субдеревьях, заданных фильтром.

6.4. Примеры фильтрации subtree

6.4.1. Нет фильтра

При отказе от фильтрации операция <get> возвращает модель данных целиком.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get/>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <!-- ... возвращается весь набор данных ... -->
       </data>
     </rpc-reply>

6.4.2. Пустой фильтр

Пустой фильтр не выберет ничего, поскольку нет совпадений содержимого или узлов выбора. Это не будет ошибкой. Атрибут type элемента, использованный в этих примерах, рассмотрен в параграфе 7.1.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get>
         <filter type="subtree">
         </filter>
       </get>
     </rpc>
     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
       </data>
     </rpc-reply>

6.4.3. Выбор всей ветви <users>

Фильтр в этом примере включает один узел выбора (<users>), поэтому фильтр выберет лишь субдерево пользователей. Этот пример представляет заполненную модель данных <users> в большинстве из приведенных ниже примеров фильтров. В реальном мире <company-info> вряд ли будет возвращаться со списком пользователей конкретного хоста или сети.

Примечание. Примеры фильтрации и конфигурации в этом документе даны в пространстве имен http://example.com/schema/1.2/config. Корневым элементом этого пространства является <top>. Элемент <top> и его потомки представляют в примере только модель конфигурационных данных.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users/>
           </top>
         </filter>
       </get-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>root</name>
               <type>superuser</type>
               <full-name>Charlie Root</full-name>
               <company-info>
                 <dept>1</dept>
                 <id>1</id>
               </company-info>
             </user>
             <user>
               <name>fred</name>
               <type>admin</type>
               <full-name>Fred Flintstone</full-name>
               <company-info>
                 <dept>2</dept>
                 <id>2</id>
               </company-info>
             </user>
             <user>
               <name>barney</name>
               <type>admin</type>
               <full-name>Barney Rubble</full-name>
               <company-info>
                 <dept>2</dept>
                 <id>3</id>
               </company-info>
             </user>
           </users>
         </top>
       </data>
     </rpc-reply>

Следующий пример дал бы такой же результат для контейнера <users> с одним дочерним элементом (<user>).

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users>
               <user/>
             </users>
           </top>
         </filter>
       </get-config>
     </rpc>

6.4.4. Выбор всех элементов <name> в ветви <users>

Этот фильтр задает два узла сдерживания (<users>, <user>) и один узел выбора (<name>). Все экземпляры элемента <name> в одном братском наборе выбираются в результат фильтрации. Клиенту может потребоваться знать, что <name> используется в этой конкретной структуре данных в качестве идентификатора экземпляра, но серверу не требуется знать эти метаданные для обработки запроса.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users>
               <user>
                 <name/>
               </user>
             </users>
           </top>
         </filter>
       </get-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>root</name>
             </user>
             <user>
               <name>fred</name>
             </user>
             <user>
               <name>barney</name>
             </user>
           </users>
         </top>
       </data>
     </rpc-reply>

6.4.5. Запись для конкретного <user>

Этот фильтр задает два узла сдерживания (<users>, <user>) и один узел сопоставления содержимого (<name>). Все экземпляры братского набора, содержащие <name> со значением fred, будут включены в результат.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users>
               <user>
                 <name>fred</name>
               </user>
             </users>
           </top>
         </filter>
       </get-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>fred</name>
               <type>admin</type>
               <full-name>Fred Flintstone</full-name>
               <company-info>
                 <dept>2</dept>
                 <id>2</id>
               </company-info>
             </user>
           </users>
         </top>
       </data>
     </rpc-reply>

6.4.6. Отдельные элементы конкретной записи <user>

Этот фильтр задает два узла сдерживания (<users>, <user>), один узел сопоставления содержимого (<name>) два узла выбора (<type>, <full-name>). Все экземпляры элементов <type> и <full-name> из братского набора, содержащие элемент <name> со значением fred будут включены в результат фильтра. Элемент <company-info> не будет включен, поскольку братский набор содержит узлы выбора.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users>
               <user>
                 <name>fred</name>
                 <type/>
                 <full-name/>
               </user>
             </users>
           </top>
         </filter>
       </get-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>fred</name>
               <type>admin</type>
               <full-name>Fred Flintstone</full-name>
             </user>
           </users>
         </top>
       </data>
     </rpc-reply>

6.4.7. Множество ветвей

Этот фильтр содержит три ветви (name=root, fred, barney).

Фильтр ветви root включает два узла сдерживания (<users>, <user>), один узел сопоставления содержимого (<name>) и один узел выбора (<company-info>). Критерии фильтрации выполняются и выходной результат содержит ветвь company-info дерева root.

Фильтр ветви fred содержит три узла сдерживания (<users>, <user>, <company-info>), один узел сопоставления содержимого (<name>) и один узел выбора (<id>). Критерии фильрации выполняются и результат будет включает <id> в ветви company-info для пользователя fred.

Фильтр ветви barney содержит три узла сдерживания (<users>, <user>, <company-info>), два узла сопоставления содержимого (<name>, <type>) и один узел выбора (<dept>). Критерии фильтра не выполняются, поскольку пользователь barney не относится к типу superuser и вся ветвь пользователя barney (включая родительский элементо <user>) исключается из финального результата.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users>
               <user>
                 <name>root</name>
                 <company-info/>
               </user>
               <user>
                 <name>fred</name>
                 <company-info>
                   <id/>
                 </company-info>
               </user>
               <user>
                 <name>barney</name>
                 <type>superuser</type>
                 <company-info>
                   <dept/>
                 </company-info>
               </user>
             </users>
           </top>
         </filter>
       </get-config>
     </rpc>

     <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>root</name>
               <company-info>
                 <dept>1</dept>
                 <id>1</id>
               </company-info>
             </user>
             <user>
               <name>fred</name>
               <company-info>
                 <id>2</id>
               </company-info>
             </user>
           </users>
         </top>
       </data>
     </rpc-reply>

6.4.8. Элементы с именованием атрибутов

В этом примере фильтр содержит один узел сдерживания (<interfaces>), одно выражение для сопоставления атрибутов («ifName») и один узел выбора (<interface>). Все экземпляры ветви <interface>, имеющие атрибут ifName со значением eth0 будут включены в результат. Элементы данных фильтра и атрибуты пригодны, поскольку непригодны атрибуты ifName не будут частью пространства имен schema/1.2.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get>
         <filter type="subtree">
           <t:top xmlns:t="http://example.com/schema/1.2/stats">
             <t:interfaces>
               <t:interface t:ifName="eth0"/>
             </t:interfaces>
           </t:top>
         </filter>
       </get>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <t:top xmlns:t="http://example.com/schema/1.2/stats">
           <t:interfaces>
             <t:interface t:ifName="eth0">
               <t:ifInOctets>45621</t:ifInOctets>
               <t:ifOutOctets>774344</t:ifOutOctets>
             </t:interface>
           </t:interfaces>
         </t:top>
       </data>
     </rpc-reply>

Если ifName будет дочерним узлом, а не атрибутом, приведенный ниже запрос даст похожий результат.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/stats">
             <interfaces>
               <interface>
                 <ifName>eth0</ifName>
               </interface>
             </interfaces>
           </top>
         </filter>
       </get>
     </rpc>

7. Операции протокола

Протокол NETCONF обеспечивает небольшой набор операций нижнего уровня для управления конфигурацией устройства и получения данные состояния. Базовый протокол обеспечивает информации для извлечения, настройки, копирования и удаления хранилищ конфигурации. Дополнительные операции могут обеспечиваться с помощью анонсируемых устройством возможностей.

Базовый протокол поддерживает следующие операции:

  • get;

  • get-config;

  • edit-config;

  • copy-config;

  • delete-config;

  • lock;

  • unlock;

  • close-session;

  • kill-session.

Протокольная операция может сталкиваться с отказами по разным причинам, включая отсутствие поддержки операции (operation not supported). Инициатору не следует надеяться, что любая операция всегда будет успешной. Возвращаемые любым откликом RPC значения следует проверять на предмет наличия ошибок.

Синтексис и представление XML для протокольных операций формаль определены в модуле YANG (Приложение C). В следующих параграфах описана семантика каждой протокольной операции.

7.1. <get-config>

Описание

Извлекает содержимое конфигурационного кланилища целиком или частично.

Параметры

source

Имя конфигурационного хранилища, из которого запрашиваются данные (например, <running/>).

filter

Этот параметр задает извлекаемые части конфигурационного хранилица. При отсутствии параметра извлекаются все данные.

Элемент <filter> может включать атрибут type, показывающий тип фильтрации в элементе <filter>. Используемый по умолчанию в NETCONF механизм фильтрации называется фильтром ветвей (subtree) и описан в разделе 6. Значение subtree явно указывает этот тип фильтрации.

Если партнер NETCONF поддерживает возможность :xpath (параграф 8.9), можно использовать xpath для индикации того, что атрибут select в элементе <filter> содержит выражение XPath.

Позитивный отклик

Если устройство может выполнить запрос, сервер передает элемент <rpc-reply>, содержащий элемент <data> с результатами запроса.

Негативный отклик

Если по какой-либо причине запрос не может быть выполнен полностью в отклик <rpc-reply> включается элемент <rpc-error>.

Пример

Для извлечения всей ветви <users> можно использовать приведенный ниже запрос.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/config">
             <users/>
           </top>
         </filter>
       </get-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>root</name>
               <type>superuser</type>
               <full-name>Charlie Root</full-name>
               <company-info>
                 <dept>1</dept>
                 <id>1</id>
               </company-info>
             </user>
             <!-- здесь могут быть дополнительные элементы <user> -->
           </users>
         </top>
       </data>
     </rpc-reply>

В разделе 6 приведены дополнительные примеры фильтрации ветвей.

7.2. <edit-config>

Описание

Операция <edit-config> загружает указанную конфигурацию целиком или частично в заданное хранилище данных конфигурации. Эта операция позволяет выразить новую конфигурацию разными способами типа записи в локальный или удаленный файл, а также в устройство (inline). Если целевое хранилище отсутствует, оно будет создано.

Если партнер NETCONF поддерживает возможность :url (параграф 8.8), вместо параметра <config> может указываться элемент <url>.

Устройство анализирует исходную и цеелвую конфигурацию и вносит запрошенные изменения. Целевая конфигурация не обязательно заменяется как в случае <copy-config>. Вместо замены она просто изменяется в соответствии с исходной конфигурацией и запрошенными действиями.

Если операция <edit-config> включает множество субопераций, применяемых к одному и тому же концептуальному узлу базовой модели данных, результат операции становится неопределенным (т. е. выходит за рамки протокола NETCONF).

Атрибуты

operation

Элементы ветви <config> могут включать атрибут operation, который относится к пространству имен NETCONF, определенному в параграфе 3.1. Атрибут указывает точку в конфигурации, к которой операция применяется, и может встречаться во множестве элементов ветви <config>.

Если атрибут operation не задан, конфигурация сливается (merge) с конфигурационным хранилищем.

Атрибут operation может принимать одно из приведенных ниже значений.

merge

Конфигурационные данные, указанные элементом, который содержит этот атрибут, объединяются с конфигурацией на соответствующем уровне в конфигурационном хранилище, заданном параметром <target>. Этот вариант применяется по умолчанию.

replace

Конфигурационные данные, указанные элементом, который содержит этот атрибут, заменяют соответствующую конфигурацию в хранилище, заданном параграфом <target>. Если таких данных нет в хранилище, они просто создаются. В отличие от операции <copy-config>, заменяющей целевую конфигурацию целиком, здесь заменяется только часть, указанная параметром <config>.

create

Конфигурационные данные, указанные элементом, который содержит этот атрибут, добавляются в конфигурацию тогда и только тогда, когда их нет в конфигурационном хранилище. Если такие данные имеются, возвращается элемент <rpc-error> с тегом ошибки (<error-tag>) data-exists.

delete

Конфигурационные данные, указанные элементом, который содержит этот атрибут, удалюяются из конфигурационного хранилища тогда и только тогда, когда они там имеются. Если таких данных нет, возвращается элемент <rpc-error> с тегом ошибки с тегом ошибки (<error-tag>) data-missing.

remove

Конфигурационные данные, указанные элементом, который содержит этот атрибут, удалюяются из конфигурационного хранилища, если они там имеются. Если таких данных нет, сервер просто игнорирует операцию remove.

Параметры

target

Имя конфигурационного хранилища, которое будет изменено (например, <running/> или <candidate/>).

default-operation

Задает принятую по умолчанию операцию (см. описание атрибута operation выше) для данного запроса <edit-config>. По умолчанию для параметра <default-operation> используется значение merge.

Параметр <default-operation> является необязательным и может принимать одно из приведенных значений:

merge

Конфигурационные данные, заданные параметром <config>, объединяются с конфигурацией на соответствующем уровне в целевом хранилище. Этот вариант применяется по умолчанию.

replace

Конфигурационные данные, заданные параметром <config>, полностью заменяют конфигурацию в целевом хранилище. Это полезно для загрузки сохраненных ранее данных конфигурации.

none

Заданная параметром <config> конфигурация не оказывает влияния на целевое хранилище, пока новые конфигурационные данные не включают атрибут operation для запроса другой операции. Если конфигурация в параметре <config> содержит данные, для которых в целевом хранилище нет соответствующего уровня, возвращается <rpc-error> с тегом ошибки (<error-tag>) data-missing. Использование none позволяет операциям типа delete избегать создания родительской иерархии для элемента, который будет удален.

test-option

Элемент <test-option> может быть задан лишь в тех случаях, когда устройство анонсирует возможность :validate:1.1 (параграф 8.6).

Элемент <test-option> может принимать одно из приведенных ниже значений.

test-then-set

Перед установкой конфигурации выполняется проверка ее пригодности. Если проверка завершилась ошибкой, операция <edit-config> не применяется. Этот вариант проверки применяется по умолчанию.

set

Конфигурация устанавливается без предварительной проверки ее пригодности.

test-only

Выполняется только проверка пригодности без попытки установить конфигурацию.

error-option

Элемент <error-option> использует одно из приведенных ниже значений.

stop-on-error

Операция <edit-config> прерывается при первой ошибке. Этот вариант применяется по умолчанию.

continue-on-error

При возникновении ошибки обработка конфигурации продолжается с записью информации об ошибке и возвратом негативного отклика.

rollback-on-error

При возникновении ошибки, которая требует генерации элемента <rpc-error>, сервер прекращает обработку операции <edit-config> и восстанавливает состояние, которое было до начала операции. Опция требует поддержки на сервере возможности :rollback-on-error, описанной в параграфе 8.5.

config

Иерархия данных конфигурации, определенных одной из моделей данных устройства. Содержимое должно помещаться в подходящее пространство имен, чтобы устройство могло определить подходящую модель данных, а также должны соблюдаться ограничения этой модели данных в соответствии с определением возможности (см. раздел 8).

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

Примеры операции <edit-config> в этом параграфе используют простую модель данных, в которой может присутствовать множество экземпляров элемента <interface>, различающихся элементами <name>.

Установка MTU 1500 на интерфейсе Ethernet0/0 в рабочей конфигурации может иметь вид

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config>
           <top xmlns="http://example.com/schema/1.2/config">
             <interface>
               <name>Ethernet0/0</name>
               <mtu>1500</mtu>
             </interface>
           </top>
         </config>
       </edit-config>
     </rpc>
     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

Добавим интерфейс Ethernet0/0 в рабочую конфигурацию, заменив имеющийся интерфейс с таким именем.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
           <top xmlns="http://example.com/schema/1.2/config">
             <interface xc:operation="replace">
               <name>Ethernet0/0</name>
               <mtu>1500</mtu>
               <address>
                 <name>192.0.2.4</name>
                 <prefix-length>24</prefix-length>
               </address>
             </interface>
           </top>
         </config>
       </edit-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

Удалим конфигурацию для интерфейса Ethernet0/0 из рабочей конфигурации.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <default-operation>none</default-operation>
         <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
           <top xmlns="http://example.com/schema/1.2/config">
             <interface xc:operation="delete">
               <name>Ethernet0/0</name>
             </interface>
           </top>
         </config>
       </edit-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

Удалим интерфейс 192.0.2.4 из области OSPF (другие интерфейсы этой области не изменяются).

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <edit-config>
         <target>
           <running/>
         </target>
         <default-operation>none</default-operation>
         <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
           <top xmlns="http://example.com/schema/1.2/config">
             <protocols>
               <ospf>
                 <area>
                   <name>0.0.0.0</name>
                   <interfaces>
                     <interface xc:operation="delete">
                       <name>192.0.2.4</name>
                     </interface>
                   </interfaces>
                 </area>
               </ospf>
             </protocols>
           </top>
         </config>
       </edit-config>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

7.3. <copy-config>

Описание

Создает или заменяет хранилище данных целиком содержимым другого полного хранилища конфигурационных данных. Если целевое хранилище существует, оно переписывается, в противном случае создается новое, когда это разрешено.

Если партнер NETCONF поддерживает свойство :url (параграф 8.8), элемент <url> может присутствовать в качестве параметра <source> или <target>. Дже в тех случаях, когда устройство анонсирует поддержку возможности :writable-running, оно может отказаться от поддержки хранилища <running/> в качестве цели (<target>) операции <copy-config>. Устройство может отказаться от поддержки операций копирования одной удаленной конфигурации в другую удаленную конфигурацию, когда оба параметра <source> и <target> используют элемент <url>. Если <source> и <target> указывают один идентификатор URL или хранилище конфигурации, должна возвращаться ошибка с тегом, содержащим invalid-value.

Параметры

target

Имя конфигурационного хранилища, в которое операция <copy-config> будет записывать данные.

source

Имя конфигурационного хранилища, служащего источником данных для операции <copy-config>, или элемент <config>, содержащий полную конфигурацию для копирования.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <copy-config>
         <target>
           <running/>
         </target>
         <source>
           <url>https://user:password@example.com/cfg/new.txt</url>
         </source>
       </copy-config>
     </rpc>
     <rpc-reply message-id="101"
         xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

7.4. <delete-config>

Описание

Удаляет конфигурационное хранилище. Хранилище рабочей конфигурации <running> не может быть удалено.

Если партнер NETCONF поддерживает возможность :url (параграф 8.8), в качестве параметра <target> может присутствовать элемент <url>.

Параметры

target

Имя удаляемого хранилища конфигурации.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <delete-config>
         <target>
           <startup/>
         </target>
       </delete-config>
     </rpc>

      <rpc-reply message-id="101"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

7.5. <lock>

Описание

Операция <lock> позволяет клиенту заблокировать конфигурационное хранилище на устройстве. Такие блокировки рассчитаны на короткое время и позвляют клиенту внести изменения, не опасаясь конфликтов с другими клиентами NETCONF или иных протоколов (например, SNMP и сценарии командного интерфейса CLI), а также с действиями операторов.

Попытка блокировки конфигурационного хранилища должна приводить к отказу, если существующая сессия или другой объект уже блокируют какую-либо часть этого хранилища.

При активной блокировке сервер должен предотвращать любые изменения заблокированных ресурсов кроме исходящих из данной сессии. Запросы SNMP и CLI на изменение ресурса должны завершаться отказом с возвратом подходящей ошибки.

Блокировка продолжается с момента ее получения до освобождения блокировки или завершения сессии NETCONF. Сессия может быть явно закрыта клиентом или неявно прекращена севером в результате отказа базового транспорта, тайм-аута бездействия, недопустимого поведения на стороне клиента. Критерии разрыва сессии зависят от реализации и базового транспорта.

Операция <lock> принимает обязательный параметр <target>, который указывает имя блокируемого конфигурационного хранилища. При активной блокировке использование заблокированного хранилища в качестве цели операции <copy-config> будет запрещено и для любой другой сессии NETCONF. Кроме того, система будет предотвращать изменение заблокированных ресурсов другими операциями управления типа SNMP или CLI. Для снятия блокировки, активизированной в другой сессии NETCONF, можно воспользоваться командой <kill-session>. Снятие блокировок, заданных другими средствами, выходит за рамки этого документа.

Блокировку недопустимо предоставлять при наличии любого из приведенных ниже условий.

  • Блокировка уже активизирована любой сессией NETCONF или другим объектом.
  • Целевая конфигурация имеет тип <candidate>, уже изменена и эти изменения не были представлены или отменены (rolled back).
  • Целевая конфигурация имеет тип <running> и другая сессия NETCONF уже представила изменения (параграф 8.4).

Сервер должен отвечать на запрос блокировки элементом <ok> или откликом об ошибке <rpc-error>.

Блокировка будет быть снята системой при разрыве установившей блокировку сессии по лобой причине.

Параметры

target

Имя конфигурационного хранилища для блокировки.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Если блокировка уже установлена, элемент <error-tag> будет иметь значение lock-denied, <error-info> будет включать <session-id> для держателя блокировки. Если блокировка задана объектом, не относящимся к NETCONF, <session-id> будет иметь значение 0. Отметим, что даже частичная блокировка целевого хранилища другим объектом будет препятствовать (глобальной) блокировке NETCONF для этого хранилища.

Пример

Приведенный ниже пример показывает успешную блокировку.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <lock>
         <target>
           <running/>
         </target>
       </lock>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/> <!-- успешная блокировка -->
     </rpc-reply>

Следующий пример показывает отказ блокировки по причине того, что хранилище уже заблокировано.

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <lock>
         <target>
           <running/>
         </target>
       </lock>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rpc-error> <!-- отказ блокировки -->
         <error-type>protocol</error-type>
         <error-tag>lock-denied</error-tag>
         <error-severity>error</error-severity>
         <error-message>
           Lock failed, lock is already held
         </error-message>
         <error-info>
           <session-id>454</session-id>
           <!-- блокировка задана сессией NETCONF с номером 454 -->
         </error-info>
       </rpc-error>
     </rpc-reply>

7.6. <unlock>

Описание

Операция <unlock> служит для снятия блокировки конфигурации, заданной ранее операцией <lock>.

Операция <unlock> не снимет блокировку при наличии любого из указанных условий:

  • указанная блокировка в данных момент не активна;
  • сессия, где задана операция <unlock>, отличается от установившей блокировку сессии.

Сервер должен отвечать на запрос снятия блокировки элементом <ok> или откликом об ошибке <rpc-error>.

Параметры

target

Имя конфигурационного хранилища для снятия блокировки.

Клиент NETCONF не может снимать блокировку конфигурационного хранилища, которую он не устанавливал.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <unlock>
         <target>
          <running/>
         </target>
       </unlock>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

7.7. <get>

Описание

Извлекает рабочую конфигурацию и данные о состоянии устройства.

Параметры

filter

Этот параметр задает часть конфигурации системы и данных состояния для извлечения информации. При отсутствии параметра возвращается вся конфигурация и данные состояния.

Элемент <filter> может включать атрибут type, показывающий тип фильтрации в элементе <filter>. Используемый по умолчанию в NETCONF механизм фильтрации называется фильтром ветвей (subtree) и описан в разделе 6. Значение subtree явно указывает этот тип фильтрации.

Если партнер NETCONF поддерживает возможность :xpath (параграф 8.9), можно использовать xpath для индикации того, что атрибут select в элементе <filter> содержит выражение XPath.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>. Раздел <data> содержит запрошенные данные.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get>
         <filter type="subtree">
           <top xmlns="http://example.com/schema/1.2/stats">
             <interfaces>
               <interface>
                 <ifName>eth0</ifName>
               </interface>
             </interfaces>
           </top>
         </filter>
       </get>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/stats">
           <interfaces>
             <interface>
               <ifName>eth0</ifName>
               <ifInOctets>45621</ifInOctets>
               <ifOutOctets>774344</ifOutOctets>
             </interface>
           </interfaces>
         </top>
       </data>
     </rpc-reply>

7.8. <close-session>

Описание

Запрашивает аккуратное прерывание сессии NETCONF.

Сервер NETCONF при получении запроса <close-session> будет аккуратно завершать сессию, освобождая все блокировки си ресурсы, связанные с сессией, а также аккуратно закрывая все связанные с ней соединения. Любые запросы NETCONF, полученные после <close-session>, будут игнорироваться.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <close-session/>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

7.9. <kill-session>

Описание

Принудительное завершение сессии NETCONF.

При получении узлом NETCONF запроса <kill-session> он будет прерывать все обрабатываемые операции, освобождать все связанные с сессией блокировки и ресурсы, а также закрывать связанные с ней соединения.

Если сервер NETCONF получает запрос <kill-session> в процессе выполнения подтверждаемого представления конфигурации (параграф 8.4), он должен восстановить конфигурацию, которая была до начала представления.

В остальный случаях операция <kill-session> не обеспечивает возврата к прежней конфигурации или отмены других изменений, внесенных задавшим блокировку объектом.

Параметры

session-id

Идентификатор прерываемой сессии NETCONF. Если это значение не совпадает с идентификатором текущей сесии, возвращается ошибка invalid-value.

Позитивный отклик

Если устройство смогло выполнить запрос, возвращается отклик <rpc-reply> с элементом <ok>.

Негативный отклик

Если запрос не выполнен полностью, возвращается отклик <rpc-reply> с элементом <rpc-error>.

Пример

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <kill-session>
         <session-id>4</session-id>
       </kill-session>
     </rpc>

     <rpc-reply message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

1Network Configuration Protocol.

2Extensible Markup Language.

3Remote procedure call.

4Internet Engineering Task Force.

5Internet Engineering Steering Group.

6Application programming interface.

7Uniform resource identifier — унифицированный идентификатор ресурса.

8Transport Layer Security.

9Secure Shell — защищенная оболочка (среда).


Часть 2.




RFC 6264 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition

Internet Engineering Task Force (IETF)                          S. Jiang
Request for Comments: 6264                                        D. Guo
Category: Informational                                           Huawei
ISSN: 2070-1721                                             B. Carpenter
                                                  University of Auckland
                                                               June 2011

 

Инкрементная модель CGN для перехода на IPv6

An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition

PDF

Тезисы

Глобальное развертывание IPv6 оказалось значительно более медленным, нежели предполагалось. По мере исчерпания адресов IPv4 вопросы перехода с IPv4 на IPv6 становятся все более важными и решаются сложнее. Механизмы перехода на уровне хостов, использующие среду с двумя стеками протоколов, не могут удовлетворить все требования. Большинство конечных пользователей не имеет опыта, требуемого для настройки и поддержки таких механизмов. Устройства CGN1 со встроенными механизмами перехода могут снизить операционные издержки в период перехода с IPv4 на IPv6 и совместного использования обоих протоколов.

В этом документе предлагается инкрементная модель CGN для перехода на IPv6. Эта модель позволяет обеспечить услуги доступа к IPv6 для хостов IPv6 и услуги доступа к IPv4 для хостов IPv4, обеспечивая существующим ISP возможность не менять свою сетевую инфраструктуру на начальном этапе перехода от IPv4 к IPv6. В отличие от CGN, как таковой, инкрементная модель CGN также поддерживает плавный переход (и способствует ему) к сетям ISP2 с двумя стеками протоколов или только IPv6. Описаны интегрируемое настраиваемое устройство CGN и адаптивный домашний шлюз (HG3). Оба типа устройств могут использоваться на разных стадиях перехода, что избавляет от необходимости многократного обновления устройств. Такое решение позволяет постепенно переходить на IPv6 в соответствии с реальными потребностями пользователей.

Статус документа

Этот документ не является спецификацией проекта стандарта Internet и публикуется с информационными целями.

Документ является результатом работы IETF4 и представляет согласованное мнение сообщества IETF. Документ был вынесен на открытое обсуждение и одобрен для публикации IESG5. Не все документы, одобренные IESG, претендуют на статус тех или иных стандартов Internet (см. раздел 2 документа RFC 5741).

Информация о статусе этого документа, обнаруженных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc6264.

Авторские права

Авторские права (c) 2011 принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

Этот документ является субъектом прав и ограничений, перечисленных в BCP 78 и IETF Trust Legal Provisions и относящихся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно, поскольку в них описаны права и ограничения, относящиеся к данному документу. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

1. Введение 2

2. Инкрементная модель CGN 2

2.1. Обзор инкрементной модели CGN 2

2.2. Выбор технологии туннелирования 3

2.3. Поведение шлюза с двумя стеками протоколов 3

2.4. Поведение CGN с двумя стеками протоколов 3

2.5. Влияние на имеющиеся хосты и необновленные сети 4

2.6. Связь между IPv4 и IPv6 4

2.7. Обсуждение 4

3. Плавный переход к инфраструктуре IPv6 4

4. Вопросы безопасности 5

5. Благодарности 5

6. Литература 5

6.1. Нормативные документы 5

6.2. Дополнительная литература 5

1. Введение

Глобального перехода на Ipv6, как прогнозировалось 10 лет назад, не произошло. Сетевые операторы не решились сделать первый шаг, поскольку IPv4 работал и продолжает работать хорошо. Однако полное истощение адресов IPv4 неизбежно. Этот вопрос анализируется в динамически обновляемом документе IPv4 Address Report6 [IPUSAGE]. Пул нераспределенных адресов IANA закончился в феврале 2011 года и на момент публикации данного документа указанный сайт предсказывал неизбежное истощение адресных пулов региональных регистраторов (RIR7). С учетом этих обстоятельств похоже, что индустрия Internet достигла согласия по вопросу неизбежности глобального развертывания IPv6 и необходимости сделать это как можно скорее.

В связи с этим вопросы перехода с IPv4 на IPv6 становятся более важными и усложняются необходимостью глобального развертывания IPv6. Механизмы перехода на уровне хостов сами по себе не способны выполнить все требования для перехода. Следовательно, требуются функции поддержки на уровне сетей и/или новые механизмы перехода, обеспечивающие простоту операций на пользовательской стороне.

Системы трансляции адресов на уровне оператора (CGN8) [CGN-REQS], которые называют также NAT444 CGN и Large Scale NAT, позволяют решить эксплуатационные проблемы IPv4, но никак не способствуют переходу с IPv4 на IPv6. Развертывание NAT444 CGN позволяет ISP отложить переход и, следовательно, вдвое повышает расходы, связанные с переходом (сначала на добавление CGN, а потом на поддержку IPv6).

Реализации CGN, интегрирующие множество механизмов перехода, могут упростить операции по обслуживанию конечных пользователей в процессе перехода с IPv4 на IPv6 и в период сосуществования протоколов. Системы CGN развертываются на строне сети и управляются/поддерживаются профессионалами. На пользовательской стороне могут потребоваться домашние шлюзы (HG). Эти устройства могут предоставляться пользователям операторами в зависимости от конкретных бизнес-моделей. Упрощенные устройства с двумя стеками протоколов (DS-Lite9) [DS-LITE] представляют собой основанное на CGN решение, которое поддерживает переход, но требуют от ISP незамедлительно перевести свою сеть на IPv6. Многие ISP не решаются сделать этот первый шаг. Теоретически устройства DS-Lite можно использовать с двойной инкапсуляцией (IPv4-in-IPv6-in-IPv4), но такое решение вряд ли будет принято ISP и не рассматривается в этом документе.

Данный документ предлагает инкрементную модель CGN для перехода на IPv6. В документе не определяются новые протоколы или механизмы, но описано использование комбинации имеющихся предложений для постепенного перехода. Модель похожа на DS-Lite, но работает иначе. Она, прежде всего, объединяет функции трансляции v4-v4 NAT с туннелированием v6-over-v4. Эта модель позволяет обеспечить услуги доступа IPv6 для хостов, поддерживающих IPv6 и услуги IPv4 для хостов IPv4 без изменения инфраструктуры IPv4 сервис-провайдера (ISP). Развертывание этой технологии не оказывает никакого влияния на унаследованные хосты IPv4 с глобально доступными адресами IPv4. Технология подходит для начальной стадии перехода с IPv4 на IPv6. Она также поддерживает переход к сетям ISP с двумя стеками протоколов и сетям, использующим только IPv6.

В документе описан также механизм постепенного перехода. Этот механизм использует интегрируемые и настраиваемые устройства CGN, а также адаптивные устройства HG. Оба типа устройств (CGN и HG) могут использоваться на разных стадиях перехода и не потребуют замены. Это позволяет переходить на IPv6 постепенно в соответствии с реальными потребностями пользователей.

2. Инкрементная модель CGN

Сегодня большинство пользователей работает с адресами IPv4. Сервис-провайдеры начинают предоставлять услуги доступа IPv6 конечным пользователям. На начальном этапе перехода от IPv4 к IPv6 связность и трафик IPv4 будут сохранять свое присутствие (и преобладание) в сетях большинства ISP. Сервис-провайдеры хотят минимизировать изменения в своих сетях IPv4. Переход всей сети ISP на использование только IPv6 будет рассматриваться, как радикальная стратегия. Переход всей сети ISP на использование двух протоколов не столь радикален, но усложняет сеть и требует дополнительных расходов. Хотя некоторые ISP успешно развернули сети с двумя протоколами, остальные предпочитают не делать этого в качестве первого этапа своего перехода на IPv6. Однако в настоящее время требуется достаточно срочно решать две проблемы — преодоление текущего дефицита адресов IPv4 путем развертывания того или иного механизма совместного использования адресов и подготовки к активному использованию адресного пространства и услуг IPv6. ISP решают одну из двух проблем путем адаптации CGN (для преодоления дефицита адресов IPv4) или 6rd (для предоставления услуг подключения по IPv6). Описанная здесь модель предназначена для решения обеих проблем за счет комбинирования технологий v4-v4 CGN и туннелирования v6-over-v4.

2.1. Обзор инкрементной модели CGN

Инкрементная модель CGN, предлагаемая здесь, схематически показана на рисунке 1.

Как показано на рисунке 1, ISP не требуется существенно менять свою сеть IPv4. Эта модель обеспечивает хостам IPv4 доступ в сеть IPv4 Internet, а хостам IPv6 — доступ в сеть IPv6 Internet. Хосты с двумя стеками протоколов трактуются, как хосты IPv4, при использовании ими услуг доступа IPv4 и, как хосты Ipv6, при использовании услуг доступа IPv6. Для обеспечения хостам IPv4 возможности доступа в сеть IPv6 Internet, а хостам IPv6 — в сеть IPv4 Internet можно интегрировать NAT64 с CGN (более подробное описание взаимодействия IPv4/IPv6 приведено в параграфе 2.6). Рассмотрение интеграции таких механизмов выходит за пределы этого документа.

                              +-------------+
                              |IPv6 Internet|
                              +-------------+
                                     |
                     +---------------+----------+
+-----+   +--+       |  Сеть IPv4 +--+--+       |   +--------+
|Хост |---|DS|=======+============| CGN |-------+---|  IPv4  |
|v4/v6|   |HG|       |    ISP     +-----+   |   |   |Internet|
+-----+   +--+       +----------------------+---+   +--------+
             _ _ _ _ _ _ _ _ _ _ _          |
           ()_Туннель_6_over_4_ _____() +-----------------------+
                                        |Существующие хосты IPv4|
                                        +-----------------------+

Рисунок 1 Инкрементная модель CGN для сети IPv4 Internet-провайдера
DS HG — домашний шлюз с двумя протоколами (CPE — оборудование на стороне пользователя).


В рассматриваемой модели нужны два типа устройств: домашние шлюзы с двумя стеками протоколов (HG) и устройства CGN с двумя стеками. Домашние шлюзы с двумя стеками протоколов интегрируют пересылку для протоколов IPv6 и IPv4 с функциями туннелирования v6-over-v4. Такие устройства следует выполнять в соответствии с требованиями [RFC6204], включая делегирование префиксов IPv6. Они могут также поддерживать функциональность v4-v4 NAT. Устройства CGN с двумя стеками протоколов интегрируют функции туннелирования v6-over-v4 и v4-v4 CGN, а также стандартную маршрутизацию IPv6 и IPv4.

Модель не требует использования новых механизмов пересылки пакетов IP, а также инкапсуляции и декапсуляции в конечных точках туннелей. В последующих параграфах описано взаимодействие HG с инкрементным CGN.

2.2. Выбор технологии туннелирования

В принципе, эта модель будет работать с любой формой туннеля между HG с двойным стеком и CGN с двойным стеком. Однако туннели, требующие явной настройки, очевидно будут нежелательны ввиду связанных с ними операционных расходов. Следовательно, настраиваемые туннели [RFC4213] не подойдут. Туннельный брокер [RFC3053] также требует операционных расходов и будет нежелателен для домашних пользователей.

Технология 6rd [RFC5569, RFC5969] представляется подходящим решением для поддержки туннелей v6-over-v4 с низкими операционными расходами. Инкапсуляция GRE10 [RFC2784] с дополнительным механизмом автоматической настройки конфигурации также подходит для поддержки туннелей v6-over-v4. Могут рассматриваться и другие механизмы туннелирования типа 6over4 [RFC2529], 6to4 [RFC3056], ISATAP11 [RFC5214] или VET12 [RFC5558]. Если ISP имеет полнофункциональную инфраструктуру MPLS между HG и CGN с двойным стеком, можно использовать также туннели 6PE13 [RFC4798] непосредственно в MPLS. Однако это решение подойдет только для устройств HG с расширенными функциями, которые сложно отнести к числу потребительских устройств, поэтому оно не будет рассматриваться подробно. Для простоты предположим использование туннелей 6rd.

2.3. Поведение шлюза с двумя стеками протоколов

Когда домашний шлюз с двойным стеком протоколов принимает пакет от хоста, он будет квалифицировать этот пакет, как IPv4 или IPv6. Принятый пакет в зависимости от результата определения будет обрабатываться стеком IPv4 или IPv6. Для IPv4 при отсутствии на шлюзе HG трансляции адресов v4-v4 NAT стек будет просто пересылать пакет устройству CGN, в качестве которого в общем случае будет служить используемый по умолчанию маршрутизатор IPv4. Если на шлюзе включена трансляция v4-v4 NAT, HG изменит в заголовке пакета адрес отправителя с приватного адреса IPv4 в зоне действия HG на адрес IPv4 в зоне действия CGN, при необходимости выполнит трансляцию портов и перешлет пакет в направлении CGN. Шлюз HG будет сохранять данные о трансляции адресов и отображении портов v4-v4 для входящих пакетов, подобно другим системам NAT.

Для IPv6 шлюз HG должен инкапсулировать данные в туннель IPv4, для которого адресатом IPv4 служит устройство CGN с двойным стеком. HG передает новый пакет IPv4 в направлении CGN, используя (например) 6rd.

Если шлюз HG связан с множеством устройств CGN, он будет сохранять данные отображения между туннелем и адресом отправителя IPv6 для входящих пакетов. Подробное рассмотрение работы множества CGN с одним шлюзом HG оставлено на будущее.

Пакеты IPv4 от CGN и инкапсулированные пакеты IPv6 от CGN будут транслироваться или декапсулироваться в соответствии с сохраненными данными об отображении и пересылаться на пользовательскую сторону шлюза HG.

2.4. Поведение CGN с двумя стеками протоколов

Когда CGN с двойным стеком протоколов получает пакет данных IPv4 от домашнего шлюза с двойным стеком, он будет определять, является ли этот пакет обычным пакетом IPv4 (без инкапсуляции) или туннелируемым пакетом v6-over-v4, адресованным конечной точке туннеля внутри этого CGN. Для обычного пакета IPv4 устройство CGN транслирует адрес отправителя в пакете из области IPv4 этого CGN в публичный адрес IPv4, выполняя при необходимости отображение портов, и затем обычным путем пересылает этот пакет в IPv4 Internet. CGN записывает данные трансляции адресов v4-v4 и отображения портов для последующей обработки входящих пакетов, как это делают обычные устройства NAT. Для туннелируемый пакетов v6-over-v4 конечная точка туннеля в CGN будет декапсулировать пакет в обычный пакет IPv6 и затем пересылать его в IPv6 Internet. CGN записывает информацию об отображении туннеля на адреса отправителя IPv6 для последующей обработки входящих пакетов.

В зависимости от места установки CGN это устройство может использовать дополнительный туннель v6-over-v4 для подключения к IPv6 Internet.

Пакеты из IPv4 Internet будут соответствующим образом транслироваться устройством CGN и пересылаться устройству HG, а пакеты из IPv6 Internet будут туннелироваться в соответствующий шлюз HG с использованием при сохраненной информации об отображениях.

2.5. Влияние на имеющиеся хосты и необновленные сети

Эта модель не оказывает никакого влияния на неизменяемые части сети ISP. Унаследованные сети IPv4 ISP и устройства IPv4 в них продолжат работать, как обычно. Имеющиеся хосты IPv4, показанные прямоугольником в нижнем правом углу на рисунке 1 и имеющие публичные (глобальные) адреса IPv4 или расположенные за трансляторами v4-v4 NAT, могут подключаться к IPv4 Internet обычным способом. Эти хосты при переходе к двойному стеку протоколов смогут подключаться к IPv6 Internet через сеть IPv4 ISP, используя туннелирование Ipv6-over-IPv4 (см. параграф 2.7, где рассмотрен размер MTU).

2.6. Связь между IPv4 и IPv6

По очевидным коммерческим причинам понятно, что полного перехода публичных услуг на IPv6 не следует ожидать, пока сохраняется достаточно большое число пользователей IPv4. Однако взаимодействие между IPv4 и IPv6 может сталкиваться с проблемами во многих вариантах реализации.

Предполагается, IETF стандартизует рекомендуемый алгоритм перехода от IPv4 к IPv6, иногда называемый NAT64. Этот алгоритм описан в перечисленных ниже документах.

  • Framework for IPv4/IPv6 Translation [RFC6144];

  • IPv6 Addressing of IPv4/IPv6 Translators [RFC6052];

  • DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [RFC6147];

  • IP/ICMP Translation Algorithm [RFC6145];

  • Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [RFC6146];

  • An FTP ALG for IPv6-to-IPv4 Translation [FTP-ALG].

Сервис, как описано в документе IETF «Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment» [RFC6180], обеспечивает трансляцию без учета состояний (stateless) между хостами в домене только-IPv4 или хостами, предоставляющими только услуги IPv4, и хостами с адресом IPv6, имеющими встроенный адрес IPv4 (IPv4-embedded IPv6), в домене только-IPv6. В дополнение к этому он обеспечивает доступ с хостов IPv6 с адресами общего формата к хостам в домене только-IPv4 или хостам, предоставляющим только услуги IPv4. Сервис не обеспечивает трансляции «все во все» (any-to-any). Одним из результатов является то, что хосты в домене IPv6 получают услуги IPv4 через трансляцию с учетом состояния (stateful). Другой результат состоит в том, что оператор сети IPv6 получает вариант переноса серверов в домен только-IPv6, сохраняя доступ к ним для клиентов только-IPv4 через трансляцию без учета состояния в адреса IPv6 со встроенными адресами IPv4.

Документ «Architectural Implications of NAT» [RFC2993] применим к службе так же, как к обычной трансляции IPv4/IPv4, с учетом того, что система с адресом IPv6, включающим адрес IPv4, доступна через NAT. Документ «Architectural Implications of NAT» [RFC2993] применяется к сервису просто как к трансляции IPv4/IPv4 за исключением того, что системы с адресом IPv6, содержащим IPv4, достижимы через NAT и в отличие от IPv4, любые допущения приложения о значимости локального адреса для удаленного партнера и любое использование адреса IP буквально в данных приложения являются прерогативой источника сервиса. В общем случае для снижения риска рекомендуются указанные ниже меры.

  • В идеале приложениям следует использовать имена DNS, а не адреса IP в идентификаторах URL, URI и ссылках, что обеспечит независимость от сетевого уровня.

  • Если этого не делается, сеть может предоставлять транслятор или прокси, охватывающий домены. Например, агент SMTP MTA14 с подключением IPv4 и IPv6 четко обрабатывает трансляцию IPv4/IPv6 на прикладном уровне.

2.7. Обсуждение

Для трафика IPv4 модель постепенного перехода CGN наследует все проблемы методов совместного использования адресов CGN [ADDR-ISSUES] (например, расширяемость и сложность поддержки общеизвестных портов для входящего трафика). Проблемы прикладного уровня, вызываемые двойным преобразованием NAT, выходят за рамки этого документа.

Для трафика IPv6 пользователи, находящиеся за DS HG, будут видеть обычный сервис IPv6. Было замечено, что MTU туннелей IPv6 размером не меньше 1500 байтов обеспечивает механизм, не вызывающий избыточной фрагментамии трафика IPv6 или избыточных взаимодействий по определению IPv6 path MTU. Вместе с отстутствием проблем NAT для IPv6 это будет стимулом для пользователей и провайдеров приложений к переходу на IPv6.

Фильтрация ICMP [RFC4890] может быть включена как часть функций CGN.

3. Плавный переход к инфраструктуре IPv6

Переход от «чистого» NAT444 CGN или 6rd к инкрементному CGN прост. Устройства HG и CGN и их местоположение не меняются и может потребоваться лишь обновление программ. В описанной ниже идеальной модели не требуется даже обновления программ и достаточно лишь изменить конфигурацию. NAT444 CGN решает проблему нехватки публичных адресов в современной инфраструктуре IPv4. Однако это не способствует развертыванию IPv6 в целом. Инкрементный CGN может наследовать функции NAT444 CGN, обеспечивая при этом наложенные услуги IPv6. механизмы 6rd можно плавно преобразовать в эту инкрементную модель CGN. Однако домашние шлюзы предется обновить для выполнения описанных ниже действий.

Инкрементный CGN можно легко перевести в поддерживающую IPv6 инфраструктуру, где сеть ISP использует оба протокола или только IPv6.

Если ISP предпочтет перейти на маршрутизацию для двух протоколов (dual-stack routing), HG следует просто отключить свою функцию v6-over-v4 при наличии трафика IPv6 RA15 или DHCPv6 и пересылать трафик IPv6 и IPv4 напрямую, а в CGN с двумя стеками сохранить льшь функцию v4-v4 NAT.

Однако предполагается, что ISP выберут подход, описанный как инкрементный CGN в этом документе, поскольку это позволит избежать маршрутизации для двух протоколов и постепенно перейти от маршрутизации IPv4 к маршрутизации только IPv6. В этом случае идеальной модель для инкрементного CGN будет интегрированное настраиваемое устройство CGN и адаптивное устройство HG. Интегрированное устройство CGN сможет поддерживать множество функций, включая NAT444 CGN, маршрутизатор 6rd (или дополнительный механизм туннелирования), DS-Lite и пересылку для двух протоколов.

HG интегрирует соответствующие функции и сможет детектировать соответствующие инкрементные изменения на стороне CGN. Обычно HG будет время от времени опрашивать CGN для определения работающих функций. Например, начав с поддержки только IPv4 (в этом случае HG считает CGN принятым по умолчанию маршрутизатором IPv4), HG обнаружит (путем нечастого опроса) доступность 6rd. Тогда домашние пользователи будут получать адреса IPv6. Позднее HG обнаружит появление естественных сообщений IPv6 Route Advertisement или DHCPv6 для определения доступности сервиса IPv6, включая DS-Lite. Таким образом, когда ISP решит перейти от инкрементного CGN на DS-Lite CGN, потребуется лишь изменить конфигурацию и слегка обновить программы на устройствах CGN. Домашние шлюзы увидят эти изменения и автоматически переключатся в режим DS-Lite. Единственным влиянием на домашних пользователей будет изменение префикса IPv6.

В модели плавного перехода устройства CGN и HG могут использоваться повторно на разных этапах перехода. Это позволяет избежать многократного обновления. Разные участки сети одного ISP могут находиться на разных этапах перехода, использующих идентичные устройство с разными конфигурациями инкрементного CGN в каждом учаске сети. Таким образом, переход на IPv6 может обеспечиваться постепенно в соответствии с реальными потребностями пользователей и ISP.

4. Вопросы безопасности

Вопросы безопасности, связанные с NAT, были рассмотрены в [RFC2663] и [RFC2993]. Проблемы безопасности для крупномасштабного использования общих адресов, включая CGN, рассмотрены в [ADDR-ISSUES]. Этот документ не добавляет новых функций в CGN и поэтому не созлает новых проблем безопасности. Вопросы безопасности 6rd рассмотрены в [RFC5569] и [RFC5969], а DS-Lite — в [DS-LITE].

Поскольку предложенные здесь туннели полностью размещаются в сети одного ISP между устрогйствами HG/CPE и CGN, модель угроз относительно проста. В [RFC4891] описана защита туннелей с использованием IPsec, но ISP могут обоснованно считать свою инфраструктуру достаточно защищенной без применения IPsec. Внутренние риски туннелей описаны в [RFC6169], где рекомендуется не передавать туннелируемый трафик через граничные маршрутизаторы. В инкрементной модели CGN эта рекомендация учтена. Для предотвращения других рисков, связанных с туннелями, важно, чтобы все механизмы защиты, основанные на проверке пакетов и все реализации входных фильтров применялись к пакетам IPv6 после их декапсуляции устройством CGN. Домашним шлюзам с двумя стеками протоколов нужно поддерживать базовые функции защиты для IPv6 [RFC6092]. Другие вопросы рассмотрены в[RFC4864].

5. Благодарности

Множество полезных замечаний было получено от Fred Baker, Dan Wing, Fred Templin, Seiichi Kawamura, Remi Despres, Janos Mohacsi, Mohamed Boucadair, Shin Miyakawa, Joel Jaeggli, Jari Arkko, Tim Polk, Sean Turner и других членов рабочей группы IETF V6OPS.

6. Литература

6.1. Нормативные документы

[RFC2529] Carpenter, B. and C. Jung, «Transmission of IPv6 over IPv4 Domains without Explicit Tunnels», RFC 2529, March 1999.

[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, «Generic Routing Encapsulation (GRE)», RFC 2784, March 2000.

[RFC5569] Despres, R., «IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)», RFC 5569, January 2010.

[RFC5969] Townsley, W. and O. Troan, «IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) — Protocol Specification», RFC 5969, August 2010.

6.2. Дополнительная литература

[RFC2663] Srisuresh, P. and M. Holdrege, «IP Network Address Translator (NAT) Terminology and Considerations», RFC 2663, August 1999.

[RFC2993] Hain, T., «Architectural Implications of NAT», RFC 2993, November 2000.

[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, «IPv6 Tunnel Broker», RFC 3053, January 2001.

[RFC3056] Carpenter, B. and K. Moore, «Connection of IPv6 Domains via IPv4 Clouds», RFC 3056, February 2001.

[RFC4213] Nordmark, E. and R. Gilligan, «Basic Transition Mechanisms for IPv6 Hosts and Routers», RFC 4213, October 2005.

[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, «Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)», RFC 4798, February 2007.

[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, «Local Network Protection for IPv6», RFC 4864, May 2007.

[RFC4890] Davies, E. and J. Mohacsi, «Recommendations for Filtering ICMPv6 Messages in Firewalls», RFC 4890, May 2007.

[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, «Using IPsec to Secure IPv6-in-IPv4 Tunnels», RFC 4891, May 2007.

[RFC5214] Templin, F., Gleeson, T., and D. Thaler, «Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)», RFC 5214, March 2008.

[RFC5558] Templin, F., Ed., «Virtual Enterprise Traversal (VET)», RFC 5558, February 2010.

[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, «IPv6 Addressing of IPv4/IPv6 Translators», RFC 6052, October 2010.

[RFC6092] Woodyatt, J., Ed., «Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service», RFC 6092, January 2011.

[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, «Framework for IPv4/IPv6 Translation», RFC 6144, April 2011.

[RFC6145] Li, X., Bao, C., and F. Baker, «IP/ICMP Translation Algorithm», RFC 6145, April 2011.

[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, «Stateful NAT64: Network Address and Protocol Translation from Ipv6 Clients to IPv4 Servers», RFC 6146, April 2011.

[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. Van Beijnum, «DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers», RFC 6147, April 2011.

[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, «Security Concerns with IP Tunneling», RFC 6169, April 2011.

[RFC6180] Arkko, J. and F. Baker, «Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment», RFC 6180, May 2011.

[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, Ed., «Basic Requirements for IPv6 Customer Edge Routers», RFC 6204, April 2011.

[IPUSAGE] G. Huston, IPv4 Address Report, June 2011, http://www.potaroo.net/tools/ipv4/index.html.

[DS-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, «Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion», Work in Progress16, May 2011.

[ADDR-ISSUES] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, «Issues with IP Address Sharing», Work in Progress17, March 2011.

[CGN-REQS] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, «Common requirements for IP address sharing schemes», Work in Progress18, March 2011.

[FTP-ALG] van Beijnum, I., «An FTP ALG for Ipv6-to-IPv4 Translation», Work in Progress19, May 2011.

Адреса авторов

Sheng Jiang

Huawei Technologies Co., Ltd

Huawei Building, No.3 Xinxi Rd.,

Shang-Di Information Industry Base, Hai-Dian District

Beijing 100085

P.R. China

EMail: jiangsheng@huawei.com

Dayong Guo

Huawei Technologies Co., Ltd

Huawei Building, No.3 Xinxi Rd.,

Shang-Di Information Industry Base, Hai-Dian District

Beijing 100085

P.R. China

EMail: guoseu@huawei.com

Brian Carpenter

Department of Computer Science

University of Auckland

PB 92019

Auckland, 1142

New Zealand

EMail: brian.e.carpenter@gmail.com

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1Carrier-Grade NAT — система трансляции сетевых адресов в масштабе оператора.

2Internet Service Provider. Прим. перев.

3Home gateway.

4Internet Engineering Task Force.

5Internet Engineering Steering Group.

6Отчет об адресах IPv4.

7Regional Internet Registry.

8Carrier-Grade NAT.

9Dual-stack lite.

10Generic Routing Encapsulation — базовая инкапсуляция маршрутной информации.

11Intra-Site Automatic Tunnel Addressing Protocol — протокол автоматической адресации туннелей внутри сайта.

12Virtual Enterprise Traversal — виртуальный проход через сеть предприятия.

13IPv6 Provider Edge.

14Mail Transfer Agent — агент доставки почты.

15Router Advertisement — анонс маршрутизатора.

16Работа опубликована в RFC 6333. Прим. перев.

17Работа опубликована в RFC 6269. Прим. перев.

18Работа опубликована в RFC 6888. Прим. перев.

19Работа опубликована в RFC 6384. Прим. перев.