draft-ietf-radext-nai-08.txt   draft-ietf-radext-nai-09.txt 
RADEXT Working Group DeKok, Alan RADEXT Working Group DeKok, Alan
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Obsoletes: 4282 Obsoletes: 4282
Category: Standards Track Category: Standards Track
<draft-ietf-radext-nai-08.txt> <draft-ietf-radext-nai-09.txt>
24 September 2014 29 October 2014
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-nai-08 draft-ietf-radext-nai-09
Abstract Abstract
In order to provide inter-domain authentication services, it is In order to provide inter-domain authentication services, it is
necessary to have a standardized method that domains can use to necessary to have a standardized method that domains can use to
identify each other's users. This document defines the syntax for identify each other's users. This document defines the syntax for
the Network Access Identifier (NAI), the user identity submitted by the Network Access Identifier (NAI), the user identity submitted by
the client prior to accessing network resources. This document is a the client prior to accessing network resources. This document is a
revised version of RFC 4282, which addresses issues with revised version of RFC 4282, which addresses issues with
international character sets, as well as a number of other international character sets, as well as a number of other
skipping to change at page 1, line 45 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 24, 2015. This Internet-Draft will expire on April 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
Appendix A - Changes from RFC4282 ............................ 3 Appendix A - Changes from RFC4282 ............................ 3
1. Introduction ............................................. 4 1. Introduction ............................................. 4
1.1. Terminology ......................................... 5 1.1. Terminology ......................................... 5
1.2. Requirements Language ............................... 6 1.2. Requirements Language ............................... 6
1.3. Purpose ............................................. 7 1.3. Purpose ............................................. 7
1.4. Motivation .......................................... 7 1.4. Motivation .......................................... 8
2. NAI Definition ........................................... 8 2. NAI Definition ........................................... 8
2.1. UTF-8 Syntax and Normalization ...................... 8 2.1. UTF-8 Syntax and Normalization ...................... 9
2.2. Formal Syntax ....................................... 9 2.2. Formal Syntax ....................................... 9
2.3. NAI Length Considerations ........................... 10 2.3. NAI Length Considerations ........................... 10
2.4. Support for Username Privacy ........................ 11 2.4. Support for Username Privacy ........................ 11
2.5. International Character Sets ........................ 11 2.5. International Character Sets ........................ 11
2.6. The Normalization Process ........................... 12 2.6. The Normalization Process ........................... 12
2.6.1. Issues with the Normalization Process .......... 13 2.6.1. Issues with the Normalization Process .......... 13
2.7. Use in Other Protocols .............................. 14 2.7. Use in Other Protocols .............................. 14
2.8. Using the NAI format for other identifiers .......... 15 2.8. Using the NAI format for other identifiers .......... 15
3. Routing inside of AAA Systems ............................ 16 3. Routing inside of AAA Systems ............................ 16
3.1. Compatibility with Email Usernames .................. 17 3.1. Compatibility with Email Usernames .................. 17
skipping to change at page 4, line 43 skipping to change at page 4, line 43
authentication framework. authentication framework.
In order to enhance the interoperability of these services, it is In order to enhance the interoperability of these services, it is
necessary to have a standardized method for identifying users. This necessary to have a standardized method for identifying users. This
document defines syntax for the Network Access Identifier (NAI). document defines syntax for the Network Access Identifier (NAI).
Examples of implementations that use the NAI, and descriptions of its Examples of implementations that use the NAI, and descriptions of its
semantics, can be found in [RFC2194]. semantics, can be found in [RFC2194].
When the NAI was defined for network access, it had the side effect When the NAI was defined for network access, it had the side effect
of defining an identifier which could be used in non-AAA systems. of defining an identifier which could be used in non-AAA systems.
Some systems defined identifiers which were compatible with the NAI, Some non-AAA systems defined identifiers which were compatible with
and deployments used the NAI. This process simplified the management the NAI, and deployments used the NAI. This process simplified the
of credentials, by re-using the same credential in multiple management of credentials, by re-using the same credential in
situations. We suggest that this re-use is good practice. The multiple situations. We suggest that this re-use is good practice.
alternative is to have protocol-specific identifiers, which increases The alternative is to have protocol-specific identifiers, which
cost to both user and administrator. increases cost to both user and administrator.
The goal of this document is to define the format of an identifier The goal of this document is to define the format of an identifier
which can be used in many protocols. A protocol may transport an which can be used in many protocols. A protocol may transport an
encoded version of the NAI (e.g. '.' as %2E). However, the encoded version of the NAI (e.g. '.' as %2E). However, the
definition of the NAI is protocol independent. We hope to encourage definition of the NAI is protocol independent. We hope to encourage
the wide-spread adoption of the NAI as an identifier. This adoption the wide-spread adoption of the NAI as an identifier. This adoption
will decrease work required to leverage identification and will decrease work required to leverage identification and
authentication in other protocols. It will also decrease the authentication in other protocols. It will also decrease the
complexity of systems for end users and administrators. complexity of non-AAA systems for end users and administrators.
We note that this document only suggest that the NAI be used, but We note that this document only suggest that the NAI be used, but
does not require such use. Many protocols already define their own does not require such use. Many protocols already define their own
identifier formats. Some of these are incompatible with the NAI, identifier formats. Some of these are incompatible with the NAI,
while others allow the NAI in addition to non-NAI identifiers. The while others allow the NAI in addition to non-NAI identifiers. The
definition of the NAI in this document has no requirements on definition of the NAI in this document has no requirements on
protocol specifications, implementations, or deployments. protocol specifications, implementations, or deployments.
However, we suggest that using one standard identifier format is However, we suggest that using one standard identifier format is
preferable to using multiple incompatible identifier formats. Where preferable to using multiple incompatible identifier formats. Where
skipping to change at page 7, line 22 skipping to change at page 7, line 22
requirements is to be able to identify the user's home authentication requirements is to be able to identify the user's home authentication
server. For use in roaming, this function is accomplished via the server. For use in roaming, this function is accomplished via the
Network Access Identifier (NAI) submitted by the user to the NAS in Network Access Identifier (NAI) submitted by the user to the NAS in
the initial network authentication. It is also expected that NASes the initial network authentication. It is also expected that NASes
will use the NAI as part of the process of opening a new tunnel, in will use the NAI as part of the process of opening a new tunnel, in
order to determine the tunnel endpoint. order to determine the tunnel endpoint.
We also hope that other protocols can take advantage of the NAI. We also hope that other protocols can take advantage of the NAI.
Many protocols include authentication capabilities, including Many protocols include authentication capabilities, including
defining their own identifier formats. These identifiers can then defining their own identifier formats. These identifiers can then
end up being transported in AAA protocols, when those systems want to end up being transported in AAA protocols, so that the originating
leverage AAA for user authentication. There is therefore a need for protocols can leverage AAA for user authentication. There is
a definition of a user identifier which can be used in multiple therefore a need for a definition of a user identifier which can be
protocols. used in multiple protocols.
While we define the NAI here, we recognize that existing protocols While we define the NAI here, we recognize that existing protocols
and deployments do not always use it. AAA systems MUST therefore be and deployments do not always use it. AAA systems MUST therefore be
able to handle user identifiers which are not in the NAI format. The able to handle user identifiers which are not in the NAI format. The
process by which that is done is outside of the scope of this process by which that is done is outside of the scope of this
document. document.
Non-AAA systems MAY accept user identifiers in forms other than the
NAI. This specification does not forbid that practice. It only
codifies the format and interpretation of the NAI. We cannot expect
to change existing protocols or practices. We can, however, suggest
that using a consistent form for a user identifier is of a benefit to
the community.
We note that this document does not make any protocol-specific We note that this document does not make any protocol-specific
definitions for an identifier format, and it does not make changes to definitions for an identifier format, and it does not make changes to
any existing protocol. Instead, it defines a protocol-independent any existing protocol. Instead, it defines a protocol-independent
form for the NAI. It is hoped that the NAI is a user identifier form for the NAI. It is hoped that the NAI is a user identifier
which can be used in multiple protocols. which can be used in multiple protocols.
Using a common identifier simplifies deployments, as there is no need Using a common identifier simplifies deployments, as there is no need
to maintain multiple identifiers for one user. It simplifies to maintain multiple identifiers for one user. It simplifies
protocols requiring authentication, as they no longer need to specify protocols requiring authentication, as they no longer need to specify
protocol-specific format for user identifiers. It increases protocol-specific format for user identifiers. It increases
skipping to change at page 9, line 27 skipping to change at page 9, line 36
See [RFC5198] and section 2.6 of this specification for a discussion See [RFC5198] and section 2.6 of this specification for a discussion
of normalization. Strings which are not in Normal Form Composed (NFC) of normalization. Strings which are not in Normal Form Composed (NFC)
are not valid NAIs and SHOULD NOT be treated as such. are not valid NAIs and SHOULD NOT be treated as such.
Implementations which expect to receive a NAI, but which instead Implementations which expect to receive a NAI, but which instead
receive non-normalised (but otherwise valid) UTF-8 strings instead receive non-normalised (but otherwise valid) UTF-8 strings instead
SHOULD attempt to create a local version of the NAI, which is SHOULD attempt to create a local version of the NAI, which is
normalized from the input identifier. This local version can then be normalized from the input identifier. This local version can then be
used for local processing. used for local processing.
Systems MAY accept user identifiers in forms other than the NAI.
This specification does not forbid that practice. It only codifies
the format and interpretation of the NAI. We cannot expect to change
existing protocols or practices. We can, however, suggest that using
a consistent form for a user identifier is of a benefit to the
community.
Where protocols carry identifiers which are expected to be Where protocols carry identifiers which are expected to be
transported over an AAA protocol, it is RECOMMENDED that the transported over an AAA protocol, it is RECOMMENDED that the
identifiers be in NAI format. Where the identifiers are not in the identifiers be in NAI format. Where the identifiers are not in the
NAI format, it is up to the AAA systems to discover this, and to NAI format, it is up to the AAA systems to discover this, and to
process them. This document does not suggest how that is done. process them. This document does not suggest how that is done.
However, existing practice indicates that it is possible. However, existing practice indicates that it is possible.
We expect that with wider use of internationalized domain names, We expect that with wider use of internationalized domain names,
existing practices will be inadequate. We therefore define the NAI, existing practices will be inadequate. We therefore define the NAI,
which is a user identifier that can correctly deal with which is a user identifier that can correctly deal with
skipping to change at page 12, line 35 skipping to change at page 12, line 37
matching the above ABNF are not valid NAIs. However, some realms matching the above ABNF are not valid NAIs. However, some realms
which do match the ABNF are still invalid NAIs. That is, matching which do match the ABNF are still invalid NAIs. That is, matching
the ABNF is a necessary, but not sufficient, requirement for an NAI. the ABNF is a necessary, but not sufficient, requirement for an NAI.
In general, the above requirement means following the requirements In general, the above requirement means following the requirements
specified in [RFC5891]. specified in [RFC5891].
2.6. The Normalization Process 2.6. The Normalization Process
Conversion to Unicode as well as normalization SHOULD be performed by Conversion to Unicode as well as normalization SHOULD be performed by
end systems that take "local" text as input. These systems are best edge systems such as laptops that take "local" text as input. These
suited to determine the users intent, and can best convert from edge systems are best suited to determine the users intent, and can
"local" text to a normalized form. best convert from "local" text to a normalized form.
Other AAA systems such as proxies do not have access to locale and Other AAA systems such as proxies do not have access to locale and
character set information that is available to end systems. character set information that is available to edge systems.
Therefore, they can not always convert local input to Unicode. Therefore, they may not always be able to convert local input to
Unicode.
That is, all processing of NAIs from "local" character sets and That is, all processing of NAIs from "local" character sets and
locales to UTF-8 SHOULD be performed by edge systems, prior to the locales to UTF-8 SHOULD be performed by edge systems, prior to the
NAIs entering the AAA system. Inside of an AAA system, NAIs are sent NAIs entering the AAA system. Inside of an AAA system, NAIs are sent
over the wire in their canonical form, and this canonical form is over the wire in their canonical form, and this canonical form is
used for all NAI and/or realm comparisons. used for all NAI and/or realm comparisons.
Copying of localized text into fields that can subsequently be placed Copying of localized text into fields that can subsequently be placed
into the RADIUS User-Name attribute is problematic. This practice into the RADIUS User-Name attribute is problematic. This practice
can result in a AAA proxy encountering non-UTF8 characters within can result in a AAA proxy encountering non-UTF8 characters within
skipping to change at page 13, line 20 skipping to change at page 13, line 22
As a result, AAA proxies expect the contents of the EAP- As a result, AAA proxies expect the contents of the EAP-
Response/Identity sent by an EAP supplicant to consist of UTF-8 Response/Identity sent by an EAP supplicant to consist of UTF-8
characters, not localized text. Using localized text in AAA username characters, not localized text. Using localized text in AAA username
or identity fields means that realm routing becomes difficult or or identity fields means that realm routing becomes difficult or
impossible. impossible.
In contrast to [RFC4282] Section 2.4, we expect AAA systems to In contrast to [RFC4282] Section 2.4, we expect AAA systems to
perform NAI comparisons, matching, and AAA routing based on the NAI perform NAI comparisons, matching, and AAA routing based on the NAI
as it is received. This specification provides a canonical as it is received. This specification provides a canonical
representation, ensures that intermediate systems such as AAA proxies representation, ensures that intermediate AAA systems such as proxies
are not required to perform translations, and can be expected to work are not required to perform translations, and can be expected to work
through systems that are unaware of international character sets. through AAA systems that are unaware of international character sets.
In an ideal world, the following requirements would be widely In an ideal world, the following requirements would be widely
implemented: implemented:
* End systems using "localized" text SHOULD normalize the NAI * Edge systems using "localized" text SHOULD normalize the NAI
prior to it being used as an identifier in an authentication prior to it being used as an identifier in an authentication
protocol. protocol.
* AAA systems SHOULD NOT normalize the NAI, as they may not have * AAA systems SHOULD NOT normalize the NAI, as they may not have
sufficient information to perform the normalization. sufficient information to perform the normalization.
There are issues with this approach, however. There are issues with this approach, however.
2.6.1. Issues with the Normalization Process 2.6.1. Issues with the Normalization Process
skipping to change at page 13, line 51 skipping to change at page 14, line 5
This identifier is treated as an opaque blob, and is placed as-is This identifier is treated as an opaque blob, and is placed as-is
into the EAP Identity field. Any subsequent system which receives into the EAP Identity field. Any subsequent system which receives
that identifier is assumed to be able to understand and process it. that identifier is assumed to be able to understand and process it.
This opaque blob unfortunately can contain localized text, which This opaque blob unfortunately can contain localized text, which
means that the AAA systems have to process that text. means that the AAA systems have to process that text.
These limitations have the following theoretical and practical These limitations have the following theoretical and practical
implications. implications.
* "local" systems used today generally do not normalize the NAI * edge systems used today generally do not normalize the NAI
* Therefore AAA systems SHOUD attempt to normalize the NAI * Therefore AAA systems SHOUD attempt to normalize the NAI
The suggestion in the above sentence contradicts the suggestion in The suggestion in the above sentence contradicts the suggestion in
the previous section. This is the reality of imperfect protocols. the previous section. This is the reality of imperfect protocols.
Where the user identifier can be normalized, or determined to be in Where the user identifier can be normalized, or determined to be in
normal form, the normal form MUST be used as the NAI. In all other normal form, the normal form MUST be used as the NAI. In all other
circumstances, the user identifier MUST NOT be treated as an NAI. circumstances, the user identifier MUST NOT be treated as an NAI.
That data is still, however, a user identifier. AAA systems MUST NOT That data is still, however, a user identifier. AAA systems MUST NOT
fail authentication simply because the user identifier is not an NAI. fail authentication simply because the user identifier is not an NAI.
skipping to change at page 16, line 20 skipping to change at page 16, line 21
requests within a AAA proxy network. The semantics of this operation requests within a AAA proxy network. The semantics of this operation
involves a logical AAA routing table, where the "utf8-realm" portion involves a logical AAA routing table, where the "utf8-realm" portion
acts as a key, and the values stored in the table are one or more acts as a key, and the values stored in the table are one or more
"next hop" AAA servers. "next hop" AAA servers.
Intermediate nodes MUST use the "utf8-realm" portion of the NAI Intermediate nodes MUST use the "utf8-realm" portion of the NAI
without modification to perform this lookup. As noted earlier, without modification to perform this lookup. As noted earlier,
intermediate nodes may not have access to the same locale information intermediate nodes may not have access to the same locale information
as the system which injected the NAI into the AAA routing systems. as the system which injected the NAI into the AAA routing systems.
Therefore, almost all "case insensitive" comparisons can be wrong. Therefore, almost all "case insensitive" comparisons can be wrong.
Where the "utf8-realm" is entirely ASCII, current systems sometimes Where the "utf8-realm" is entirely ASCII, current AAA systems
perform case-insensitive matching on realms. This practice MAY be sometimes perform case-insensitive matching on realms. This practice
continued, as it has been shown to work in practice. MAY be continued, as it has been shown to work in practice.
We also note that many existing systems have user identifiers which We also note that many existing non-AAA systems have user identifiers
are similar in format to the NAI, but which are not compliant with which are similar in format to the NAI, but which are not compliant
this specification. For example, they may use non-NFC form, or they with this specification. For example, they may use non-NFC form, or
may have multiple "@" characters in the user identifier. they may have multiple "@" characters in the user identifier.
Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior
to looking up the "utf8-realm" in the logical routing table. to looking up the "utf8-realm" in the logical routing table.
Intermediate nodes MUST NOT modify the identifiers that they forward. Intermediate nodes MUST NOT modify the identifiers that they forward.
The data as entered by the user is inviolate. The data as entered by the user is inviolate.
The "utf8-realm" provisioned in the logical AAA routing table SHOULD The "utf8-realm" provisioned in the logical AAA routing table SHOULD
be provisioned to the proxy prior to it receiving any AAA traffic. be provisioned to the proxy prior to it receiving any AAA traffic.
The "utf8-realm" SHOULD be supplied by the "next hop" or "home" The "utf8-realm" SHOULD be supplied by the "next hop" or "home"
system that also supplies the routing information necessary for system that also supplies the routing information necessary for
packets to reach the next hop. packets to reach the next hop.
This "next hop" information may be any of, or all of, the following This "next hop" information may be any of, or all of, the following
information: IP address; port; RADIUS shared secret; TLS certificate; information: IP address; port; RADIUS shared secret; TLS certificate;
DNS host name; or instruction to use dyanmic DNS discovery (i.e. look DNS host name; or instruction to use dyanmic DNS discovery (i.e. look
up a record in the "utf8-realm" domain). This list is not up a record in the "utf8-realm" domain). This list is not
exhaustive, and my be extended by future specifications. exhaustive, and my be extended by future specifications.
It is RECOMMENDED to use the entirety of the "utf8-realm" for the It is RECOMMENDED to use the entirety of the "utf8-realm" for the
routing decisions. However, systems MAY use a portion of the routing decisions. However, AAA systems MAY use a portion of the
"utf8-realm" portion, so long as that portion is a valid "utf8-realm" portion, so long as that portion is a valid
"utf8-realm", and that portion is handled as above. For example, "utf8-realm", and that portion is handled as above. For example,
routing "fred@example.com" to a "com" destination is forbidden, routing "fred@example.com" to a "com" destination is forbidden,
because "com" is not a valid "utf8-realm". However, routing because "com" is not a valid "utf8-realm". However, routing
"fred@sales.example.com" to the "example.com" destination is "fred@sales.example.com" to the "example.com" destination is
permissible. permissible.
Another reason to forbid the use of a single label (e.g. Another reason to forbid the use of a single label (e.g.
"fred@sales") is that many systems treat a single label as being a "fred@sales") is that many non-AAA systems treat a single label as
local identifier within their realm. That is, a user logging in as being a local identifier within their realm. That is, a user logging
"fred@sales" to a domain "example.com", would be treated as if the in as "fred@sales" to a domain "example.com", would be treated as if
NAI was instead "fred@sales.example.com". Permitting the use of a the NAI was instead "fred@sales.example.com". Permitting the use of
single label would mean changing the interpretation and meaning of a a single label would mean changing the interpretation and meaning of
single label, which cannot be done. a single label, which cannot be done.
3.1. Compatibility with Email Usernames 3.1. Compatibility with Email Usernames
As proposed in this document, the Network Access Identifier is of the As proposed in this document, the Network Access Identifier is of the
form "user@realm". Please note that while the user portion of the form "user@realm". Please note that while the user portion of the
NAI is based on the BNF described in [RFC5198], it has been modified NAI is based on the BNF described in [RFC5198], it has been modified
for the purposes of Section 2.2. It does not permit quoted text for the purposes of Section 2.2. It does not permit quoted text
along with "folding" or "non-folding" whitespace that is commonly along with "folding" or "non-folding" whitespace that is commonly
used in email addresses. As such, the NAI is not necessarily used in email addresses. As such, the NAI is not necessarily
equivalent to usernames used in e-mail. equivalent to usernames used in e-mail.
skipping to change at page 18, line 47 skipping to change at page 18, line 47
dynamic discovery, or other means not specified here. Note that the dynamic discovery, or other means not specified here. Note that the
first condition is affected by roaming, as the availability of the first condition is affected by roaming, as the availability of the
other realm may depend on the user's location or the desired other realm may depend on the user's location or the desired
application. application.
The use of the home realm MUST be the default unless otherwise The use of the home realm MUST be the default unless otherwise
configured. configured.
3.3.1. Historical Practices 3.3.1. Historical Practices
Some systems have historically used NAI modifications with multiple Some AAA systems have historically used NAI modifications with
"prefix" and "suffix" decorations to perform explicit routing through multiple "prefix" and "suffix" decorations to perform explicit
multiple proxies inside of a AAA network. This practice is NOT routing through multiple proxies inside of a AAA network. This
RECOMMENDED for the following reasons: practice is NOT RECOMMENDED for the following reasons:
* Using explicit routing paths is fragile, and is unresponsive to * Using explicit routing paths is fragile, and is unresponsive to
changes in the network due to servers going up or down, or to changes in the network due to servers going up or down, or to
changing business relationships. changing business relationships.
* There is no RADIUS routing protocol, meaning that routing paths * There is no RADIUS routing protocol, meaning that routing paths
have to be communicated "out of band" to all intermediate AAA have to be communicated "out of band" to all intermediate AAA
nodes, and also to all end-user systems (supplicants) expecting to nodes, and also to all edge systems (e.g. supplicants) expecting
obtain network access. to obtain network access.
* Using explicit routing paths requires thousands, if not * Using explicit routing paths requires thousands, if not
millions of end-user systems to be updated with new path millions of edge systems to be updated with new path information
information when a AAA routing path changes. This adds huge when a AAA routing path changes. This adds huge expense for
expense for updates that would be better done at only a few AAA updates that would be better done at only a few AAA systems in the
systems in the network. network.
* Manual updates to RADIUS paths are expensive, time-consuming, * Manual updates to RADIUS paths are expensive, time-consuming,
and prone to error. and prone to error.
* Creating compatible formats for the NAI is difficult * Creating compatible formats for the NAI is difficult
when locally-defined "prefixes" and "suffixes" conflict with when locally-defined "prefixes" and "suffixes" conflict with
similar practices elsewhere in the network. These conflicts mean similar practices elsewhere in the network. These conflicts mean
that connecting two networks may be impossible in some cases, as that connecting two networks may be impossible in some cases, as
there is no way for packets to be routed properly in a way that there is no way for packets to be routed properly in a way that
meets all requirements at all intermediate proxies. meets all requirements at all intermediate proxies.
 End of changes. 23 change blocks. 
57 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/