There are of course some issues surrounding network prefix translation, which is used in NAT66, GSE, and ILNP. I forwarded this text to Margaret for her to think about in the next NAT66 revision; it or something like it might be worth considering in an ILNP-related document or in the recommendation.
Begin forwarded message: > <section anchor="network" title="Network Issues"> > <t>There are issues in the deployment of networks using Network Prefix > Translation technology. These build on concepts raised in <xref > target="RFC2993"></xref> and <xref target="RFC3424"></xref> in the IPv4 > domain, and add specific issues deriving from. These considerations > apply to GSE or any GSE-like architecture, including <xref > target="I-D.rja-ilnp-dns">ILNP</xref><xref > target="I-D.rja-ilnp-icmp"></xref><xref > target="I-D.rja-ilnp-intro"></xref><xref > target="I-D.rja-ilnp-nonce"></xref>.</t> > > <t>Three fundamental concerns arise in the use of Network Address > Translation as performed in IPv4 networks: <list style="symbols"> > <t>The translator is obliged to maintain mapping state between > address domains,</t> > > <t>Systems in one domain have no way to know what address to use to > access systems in another domain, and</t> > > <t>The system itself has no such knowledge either.</t> > </list></t> > > <t>Network prefix translation as described in this document, in ILNP, > and in other proposals, lacks the issue of maintaining state - apart > from configuring the prefixes of the two domains in the translator there > is no such state - but the issues of end to end transparency remain in > an altered form. Any system that has an address in one domain is > reachable from the other, but there is a question of determining what > address to use for the purpose. Here, we try to tease apart the > issues.</t> > > <section anchor="mismatch" title="Mismatched Prefix Lengths"> > <t>The translation algorithm assumes that the two domains have the > same prefix length. If the internal domain is using a ULA (which is a > /48) and the external domain is using a longer prefix such as a /56, > /60, or /64, the translation is undefined. The simplest solution is > to, at configuration time, extend the shorter prefix to the length of > the longer by appending a fixed bit string such as zeroes.</t> > > <t>For example, in a network that uses only link-local addresses in > the private domain and a provider-allocated /64 in the public domain, > the interior side of the translator is configured with FE80::/64 and > the external domain is configured with the provider-allocated /64. > Similarly, if the internal domain is using a ULA, such as > FD12:3456:789A::/48, and the external domain is using a /56 such as > 2001:db8:1234:5600::/56, the two domains would be configured as > FD12:3456:789A:0000::/56 and 2001:db8:1234:5600::/56 respectively, and > externally addressable internal subnets would limited to > FD12:3456:789A:0000::/56. Note that the other subnets in the ULA are > still usable internally, but will not be correctly translated by the > translator and so are internal-only.</t> > > <t>Note that the suggested link-local configuration may not work in > practice; since link-local addresses are of local scope, end systems > would not generally use them to communicate with a systems whose > address has global scope.</t> > </section> > > <section anchor="on-path-attack" > title="Issue: Host identification and routing"> > <t>A characteristic of GSE-style systems in a multi-homed environment > is that the response to a request (such as the SYN-ACK in response to > a TCP SYN, R1 response to HIP's I1, or IKE_SA_INIT response in IKEv2) > may come from a different prefix (locator) than the request went to. > There are two possible solutions to the problems that creates: either > the session initiator must try different addresses until he gets the > response he expects, or (as in <xref > target="I-D.rja-ilnp-nonce">ILNP</xref>) an additional value must be > included in the exchange to disambiguate possible responses from > possible attacks.</t> > > <t>Mike O'Dell's original note noted that it would be nice if > re-routing of multihomed prefixes happened within the duration of an > RTT, so that a message that expected a given translator to service it > could be re-routed through another without loss. Practically speaking, > while this happens, it is not the normal case. Loss resulting from > network changes will be picked up by host retransmission, and may > change the prefixes (locator) used by the systems as seen by each > other.</t> > </section> > > <section anchor="dns" title="DNS Considerations"> > <t>It is necessary for any system named in DNS to be reachable from > any domain that might legally reach it. A system that is only for > internal access might only have its ULA in DNS and not external > addresses; a system that is reachable by an internal ULA and several > provider-allocated prefixes needs to list the ULA and the PA addresses > in its DNS record.</t> > > <t>In networks using traditional Dynamic DNS, a mechanism similar to > <xref target="RFC5389">STUN</xref> is necessary to enable systems to > determine their "outside" addresses. The one difference is that this > is done once or periodically, not on every session. Alternatively, the > DNS system itself might identify AAAA records being filed (whether > using Dynamic DNS or more static systems) with the internal ULA and > generate the corresponding external addresses.</t> > > <t>In general, the DNS will work more reliably if internally-generated > requests for the addresses of internal systems are answered with the > internal address and externally-generated requests for the same names > get external addresses. If all of the addresses are given on every > request, one can expect the source address selection mechanism to > prefer the internal address as it is "most similar" to the sender's > address, but external requesters have some probability of a failed > attempt using the internal address.</t> > </section> > > <section anchor="app" title="Other application considerations"> > <t>Beyond the issues of DNS, there are many applications that in IPv4 > networks that make statements to their peers about IP addresses. The > vast majority do not, which is the set of systems that work reasonably > well through NATs. Examples of some that do include <list > style="hanging"> > <t hangText="HTTP/HTTPS:">HTTP Referrals, using the Referer > object, are intended to use names in their URI, but frequently use > addresses either to identify the actual system (for debug > purposes) or because there is no obvious name. In a GSE > environment, referrals should use names.</t> > > <t hangText="SMTP:">SMTP envelopes, in the "Received" lines, > frequently record both the name and address of an interface. In a > GSE environment, the name is important.</t> > > <t hangText="SIP/SDP:">In a SIP session setup, the SDP exchange > tells the endpoints each other's addresses. This should go through > their proxy, which should be in the same system as or in parallel > with the translator.</t> > > <t hangText="FTP Active Mode:">FTP Active Mode should send a name, > not an address.</t> > </list></t> > > <t>In general, the right solution to the issues caused by separated > address spaces is to use a proxy at the boundary or to use names, so > that the peer is forced to look up the correct address in its > domain.</t> > </section> > > <section anchor="PIPA" title="Implications for the larger network"> > <t>The primary value of using a GSE-like model in the network is that > it enables the edge network to behave as if it has a > provider-independent and therefore portable address, and for the > providers of the Internet to treat addressing as if it were > provider-allocated and therefore highly aggregated.</t> > </section> > </section> > > <references title="Informative References"> > <?rfc include="reference.RFC.5389" ?> > > <?rfc include="reference.RFC.3424" ?> > > <?rfc include="reference.RFC.2993" ?> > > <?rfc include="reference.I-D.rja-ilnp-dns"?> > > <?rfc include="reference.I-D.rja-ilnp-icmp"?> > > <?rfc include="reference.I-D.rja-ilnp-intro"?> > > <?rfc include="reference.I-D.rja-ilnp-nonce"?> > > <?rfc include="reference.I-D.ietf-ipngwg-gseaddr"?> > </references> > http://www.ipinc.net/IPv4.GIF _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
