Subject: [BEHAVE] Comments on prefix format requirements

From: Fred Baker <[email-masked]>
Date: Mon, 27 Jul 2009 11:24:27 +0200

Commenting on  http://www.ietf.org/proceedings/75/slides/behave-8.pdf

Slide 3:
> Prefix Requirements
> IPv4-”Mapped”:
> 1.With IPv6 network, an IPv4-mapped prefix MUST map to a unique IPv4  
> network
> 2.Prefix MUST be short enough to allow more-specifics for multiple  
> translators
> 3.IPv6 nodes SHOULD be able to distinguish IPv4-mapped vs. native  
> IPv6 addresses
>
> IPv4-”Translatable (stateless only):
> 4.Prefix MUST be <= 64 bits to work with stateless addrconf
>
> Both:
> 5.MUST NOT inject into IPv6 network a route for every route in the  
> IPv4 Internet
> 6.SHOULD be deployable with no code changes to existing hosts
> 7.SHOULD only require routing on 80 bits or less

Slide 6:
> Address Format Requirements
>
> 1.MUST be 1-1 and reversible
> 2.MUST NOT change meaning of universal/local bit (71stbit) in IPv6  
> address unless starts with binary 000
> 3.SHOULD provide space to number multiple translators if “mapped”  
> address
> 4.SHOULD be checksum-neutral if stateless
> 5.SHOULD allow v4-dotted decimal in addr(which requires IPv4 in last  
> 32 bits)
> 6.SHOULD support (optional) IPv4 topology hiding (for “IPv6  
> Internet”<->”an IPv4 network” mapped addrs)
> 7.MAY hide IPv4 addrfor “helpful” NATs

In writing RFCs 1122/1123 and 1812, which is where the terms "MUST",  
"SHOULD", and "MAY" originated, Bob and I tried to follow a basic rule  
in tagging requirements:

a) if a requirement is flagged as "MUST", it should be only when  
failing the requirement caused something fundamental to break, and one  
should be able to state what breaks. For example, with the notion that  
an address "MUST be 1-1 and reversible", a stateless translator that  
failed this would not be able to reliably target a datagram from one  
network to a specific host in the other.

b) a requirement is flagged as "SHOULD" when there is a strong  
consensus in the working group that it should generally hold, but the  
working group could not identify a specific breakage case or  
(especially) could identify a case in which the requirement did not  
apply. For example, the desire for a checksum-neutral address makes  
sense if one is going to use IPsec ESP across the boundary, as one  
will be unable to find the UDP/TCP headers to update the interior  
checksum. That said, we have a present existence proof that IPsec ESP  
is not a requirement in the IPv4 Internet across a 4/4 NAT.

It would be helpful to me if the document identified the basis for the  
classification.

In referring to the requirements above, I will use the shorthand  
(slide)(line #) for brevity.

(3)(6) seems to me like it SHOULD be a MUST. The whole point is to  
facilitate deployment of IPv6 in a manner that naturally leads to  
universal deployment of IPv6. Modifying IPv6 in a manner that will  
survive the adoption interval seems counterproductive.

(3)(7) (prefix 80 bits or less) makes little sense to me. I understand  
that there is concern with some present implementations. It seems to  
me that this is a transitory issue; if there is a requirement to run  
at line rate with a 120 bit prefix, the extra memory read is something  
that can be addressed at a cost, and the market will choose  
implementations that lack the limitation.

As noted, (6)(1) is a no-brainer. Nothing works without it.

(6)(2) is seems pointless. The prefix that is being used by manually- 
assigned IPv4-mapped addresses will not be advertised in an RA for use  
in SLAAC. As such, the interpretation of the "universal" flag is moot.  
Present experience in the CERNET prototype supports the observation.

(6)(3) is worded in a way that I find difficult to parse  
operationally. If I have multiple translators, I would expect to be  
able to use translators that inject a given prefix into the IPv4 or  
IPv6 network to be usable interchangably, and if a specific translator  
should be used for a longer prefix, it would inject a longer prefix.  
As such, this is not a matter of providing space to multiple  
translators, but the ability for them to advertise an appropriate  
prefix for the portions of the network that they are appropriate to.  
Am I missing something fundamental here?

(6)(4) is something I am willing to support, as it enables IPsec ESP  
usage. I would be concerned, however, if it meant that a given host  
had to accept a prefix instead of an address, for example if the  
selection of differing transports triggered a need to accept differing  
addresses.

(6)(5), as I said at the mike, seems at odds with (2), as we are  
forced into either providing an algorithm for translation between the  
ASCII and binary address formats or precluded from using some prefix  
lengths. That said, in context I think (2) is bogus - one will not be  
using SLAAC, either the EUI-64 or private address versions, along with  
this class of addresses.

(6)(6) seems also bogus. I understand that some folks have a desire  
for topology hiding. However, short of actual NAT (this is protocol  
translation, not address translation), I don't see how one truly hides  
topology, especially given the information leaked in other areas such  
as SMTP Envelopes. I would like to see this better justified before we  
wrap ourselves around that axle.

(6)(7) seems the function of the "helpful" NAT, not of the translator.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Jul 2009 10:11:58 +1200

I mainly agree with Fred, except for two points:

> Commenting on  http://www.ietf.org/proceedings/75/slides/behave-8.pdf

...
>> 3.SHOULD provide space to number multiple translators if “mapped” address

...
> (6)(2) is seems pointless. The prefix that is being used by
> manually-assigned IPv4-mapped addresses will not be advertised in an RA
> for use in SLAAC. As such, the interpretation of the "universal" flag is
> moot. Present experience in the CERNET prototype supports the observation.

I don't think that is quite the point. The point is that if (and it's
a big if) we ever try to retro-fit some form of 8+8 to the Internet,
the U flag needs to be trustworthy, since 8+8 requires universally
unique IIDs. That's an architectural change that IMHO is clearly out
of BEHAVE's scope and belongs in 6MAN. I see that Rémi D has started
a thread on that in 6MAN.

...

> (6)(6) seems also bogus. I understand that some folks have a desire for
> topology hiding. However, short of actual NAT (this is protocol
> topology, especially given the information leaked in other areas such as
> SMTP Envelopes. I would like to see this better justified before we wrap
> ourselves around that axle.

I agree that it's bogus and can be addressed otherwise (see RFC4864).
But the message we got while developing 4864 was that ducking this issue
is not an option. So I would keep it, but with the parentheses around
"optional" removed, to be quite clear:
   SHOULD support OPTIONAL IPv4 topology hiding

     Brian

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 28 Jul 2009 02:14:55 -0700

> a thread on that in 6MAN.

Yes, we definitely should discuss this in 6MAN.

FWIW I don't see any utility in remote interpretation of the U-flag. It 
was added as a result of the 8+8/GSE discussion as being potentially 
useful for multihoming. I've explored many different ways to do 
multihoming and read about a few more, but I've seen no worked out 
proposal which would benefit from a remote node using the U bit in the 
interface ID.
Even if one were to invent such a protocol today, that protocol would 
have to consider interoperating with temporary IPv6 addresses and Secure 
Neighbor Discovery; two cases when U flag is not set.

    Erik