Subject: [BEHAVE] Review: draft-ietf-behave-address-format-03

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Dec 2009 11:02:35 +0100

This is my review of draft-ietf-behave-address-format-03

I've been listening to the audio archives of the sessions in Hiroshima, and I must say that I'm very surprised. One after another, people at the microphone spoke out for simplicity. But I don't find this reflected in the document.

Apparently, the authors got swept away by considering how to best solve a bunch of problems and thereby losing sight of whether these problems needed solving in the first place, and whether those solutions should be IETF standards track.

In my opinion, the document needs to be rewritten such that it only contains the text about a /96 well-known prefix and explains that service providers are free to use their own address space for IPv6-IPv4 translation as well, and stop there.

Unless I missed something, the push to include specifications of how use a non /96 prefix and/or non-WKP prefix came from a very small group of people, I see no evidence that this is something that the industry as a whole is interested in. As such, it makes much more sense to keep all of this out of this document and create a separate document that describes all of this if and when desired, rather than tie all this complexity to the current NAT64 effort.

The complexity that I'm talking about is additional logic in DNS64 and translator implementations, possible additional configuration settings that must be managed, increased difficulty when troubleshooting and constructing individual mapped addresses by hand. I also consider prefixes shorter than /64 wasteful, shorter than /48 unacceptably so.

Apart from that, there are two things missing from the document:

The first is a discussion how a well known prefix allows for referals that work between hosts using different translators, while a network specific prefix doesn't.

Second, the document needs to update RFC 3484 by making the well known prefix less preferred than IPv4. So a default policy table would have to look something like this:

      Prefix        Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      2002::/16             30     2
      ::/96                 20     3
      ::ffff:0:0/96         10     4
-->   64:ff9b::/96           5     1

Details:

Let's start on the third line:

Obsoletes: 2765 (if approved)

This document only talks about the prefix. 2765 is much wider, it specifies how to translate between IPv4 and IPv6. As such, this document can't obsolete RFC 2765, at least not on its own. I think this would need to be "updates".

      64:FF9B::/96

It might be useful to first mention this prefix in the form 0064:FF9B::/96. The first time I saw it I first thought this was in the 6400:: range rather than the 0064:: range.

   format is common to both "IPv4-Converted" and "IPv4-Translatable"

I guess this explains the presence of definitions of these terms in the framework document. However, it is very unsatisfying to define something in one document that is not used in that document and then use it in another document where it's not defined. Please solve this in some way. Also see my remarks about terminology in my review of the framework document. Oh wait, there are terminology definitions in the notations subsection. Not good enough, first define, then use, not the other way around.

The rest of the subsection, which explains where things are explained later, is superfluous.

In figure 1: counterintuitive that the prefix length comes first, while it comes last in prefix notation. Adding a / would also help clarity.

Why is it "4" and "8" but "zero"? Style guidelines usually say to spell out numbers upto twelve, but using digits for 0 - 12 could be considered more appropriate. But in that case it goes for 0, too.

   addresses constructed using the Well Known Prefix or a /96 Network
   Specific Prefix may be represented using the alternative form

If you link to RFC 2119 it's a very bad idea to use the word "may" in lower caps. And I think it should be SHOULD.

Table 1: I don't think 192.0.2.33 makes for a good example address because the 0 octet will be compressed away in certain hexadecimal representations.

There's no need to write "Table" with a capital T.

   The Well-Known Prefix SHOULD NOT be used to construct IPv4-
   Translatable addresses

This is an example of why I dislike inventing terminology: it is completely unclear to me what this sentence means, I have to go back the terminology section (which is called "notation") to figure it out. This sentence should be able to stand on its own, that's more efficient and makes it possible to quote it out of the context of the document.

As to the meaning: I don't think it's made sufficiently clear that the prefix we're talking about is for representing the IPv4 address space within the IPv6 adddress space, and NOT for numbering IPv6 hosts from. If that were well-understood this whole warning wouldn't be necesary.

   The Well-Known Prefix MUST NOT be used to represent non global IPv4
   addresses, such as those defined in [
RFC1918
].  Doing so would
   introduce ambiguous IPv6 addresses.

Say why this is a bad thing, I assume referrals etc.

3.2.  Impact on Inter-Domain Routing

Refer to the 6to4 prefix. Also explicitly say that the WKP MUST be filtered by default unless special arrangements have been made, both in incoming and outgoing route advertisements.

   Organizations deploying stateless IPv4/IPv6 translation SHOULD assign
   a Network Specific Prefix to their IPv4/IPv6 translation service.

Ok, maybe I'm being dense here, but why exactly?

   combination of the "prefix" and the IPv4 address.  In theory, routers
   should be able to route on prefixes of any length.  However, routing
   on prefixes larger than 64 bits may be slower.

Why is this relevant to the discussion at hand?

As long as you don't split the IPv4 space into blocks that are routed differently and don't use the /64 the /96 translation prefix resides in for something else (both bad ideas) there is no issue. 

   If a /32 prefix is used, all the routing bits are contained in the
   top 64 bits of the IPv6 address, leading to excellent routing
   properties. 

Right, because we want to route every translated IPv4 address individually </sarcasm>

It would be ridiculous to waste a network specific /32 for this purpose, even if someone were to consider routing every IPv4 address a useful feature.

   Intermediate prefix lengths such as /40, /48 or /56 appear as
   compromises.  Only some of the IPv4 bits are part of the /64
   prefixes.  Reverse path checks, in particular, may have a limited
   efficiency.

One more reason to reject the idea of splitting the translated IPv4 space into smaller pieces.

   The stateful nature of the translation creates a potential stability
   issue when the organization deploys multiple translators.  If several
   translators use the same prefix, there is a risk that packets
   belonging to the same connection may be routed to different
   translators as the internal routing state changes.  This issue can be
   mitigated either by assigning different prefixes to different
   translators, or by ensuring that all translators using same prefix
   coordinate their state.

Nonsense. You mitigate the issue by making sure routing delivers packets consistently to the same translator.

   The Well Known Prefix SHOULD be
   used in most scenarios, with two exceptions:
   o  In all scenarios, the translation MAY use a Network Specific
      Prefix, if deemed appropriate for management reasons.

A SHOULD doesn't preclude a MAY of the opposite so this point is superfluous.

   In the case of stateless translation, there would be no need for the
   translator to recompute complement to 1 checksum if both the IPv4-
   Translatable addresses and the IPv4-Converted address were
   constructed in a "checksum-neutral" manner,

More generally: if the combination of both address is checksum-neutral. So in theory it's possible to choose any source address and then select the (destination) translation addresses such that they compensate for the checksum difference between the IPv6 source address and IPv4 source address. In current scenarios that's not of much use but it could be in a NAT464 or some such scenario, where it might be useful to compensate the checksum differences in the source address.

Not sure though why these bits would have to go in a suffix rather than the prefix.

5.  IANA Considerations

   The Well Known Prefix falls into the range ::/8 reserved by the IETF.
   The prefix definition does not require an IANA action.

IANA would still have to put the WKP in http://www.iana.org/assignments/ipv6-address-space/ though.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 23 Dec 2009 15:45:22 +0000

> Apparently, the authors got swept away by considering how to best solve a bunch of problems 
> and thereby losing sight of whether these problems needed solving in the first place, 
> and whether those solutions should be IETF standards track.

The problems that we address were the problems that we were chartered to address.

> Unless I missed something, the push to include specifications of how use a non /96 prefix 
> and/or non-WKP prefix came from a very small group of people, I see no evidence that this 
> is something that the industry as a whole is interested in. As such, it makes much more sense 
> to keep all of this out of this document and create a separate document that describes 
> all of this if and when desired, rather than tie all this complexity to the current NAT64 effort.

The non /96 are useful for stateless translation, a problem that we were explicitly required to address. Specifically, safe deployment of IPv4 translatable IPv6 Addresses requires using prefixes in IGP tables for forwarding and source address checks, and this is better doe with shorter prefixes.

> Second, the document needs to update RFC 3484 by making the well known prefix less preferred than IPv4. 

Can't that be left to the revision of RFC 3484?

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Dec 2009 16:57:31 +0100

> The non /96 are useful for stateless translation, a problem that we were explicitly required to address. Specifically, safe deployment of IPv4 translatable IPv6 Addresses requires using prefixes in…

If the translator prefix is a /96 you can still put the /64 that that /96 falls under in the routing tables.

> Can't that be left to the revision of RFC 3484?

It should be in that, too, yes. Is it coming out anytime soon?

But since this document introduces the WKP the document should also explain how it fits in with the policy table, especially as an important reason to use the WKP is that it can have lower priority than IPv4, which solves potential issues in dual stack deployments.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 23 Dec 2009 18:03:54 +0000

So, Iljitsch, if I summarize your request, you would like to see two additions to the current draft:

1) A paragraph explaining the benefits of using the Well Known Prefix whenever possible, i.e. the property that most translators will understand it, etc.

2) A section about routing preferences, calling for an update to RFC 3484.

If these additions do not change the overall balance of the document, we can add them in a revised draft after last call. Do you have candidate text, by any chance?

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Dec 2009 19:15:12 +0100

> So, Iljitsch, if I summarize your request, you would like to see two additions to the current draft:

Yes, and one big removal of all the non-/96 NSP stuff.

> 1) A paragraph explaining the benefits of using the Well Known Prefix whenever possible, i.e. the property that most translators will understand it, etc.

And especially referrals, yes.

> 2) A section about routing preferences, calling for an update to RFC 3484.

Right.

> If these additions do not change the overall balance of the document, we can add them in a revised draft after last call. Do you have candidate text, by any chance?

Not at this time.

About the WKP load balancing issue: perhaps it's enough to just reserve 64:ff9b::/32 (ugh, I've been writing it wrong in earlier messages today) as "possible future WKP-like uses" which would of course get the same treatment in the policy table but not not specify how anything but the /96 works, leaving that until there is some real-world experience. Which is in line with what I want for the NSP.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Dec 2009 08:38:32 +1300

> Yes, and one big removal of all the non-/96 NSP stuff.

I don't think you've shown consensus for that. Personally, I fear that
if we don't lay this out precisely, we are inviting implementors and
operators to make up their own solutions.

> And especially referrals, yes.

What do you mean about referrals?

>> 2) A section about routing preferences, calling for an update to RFC 3484.

I would avoid formal "updates" language in the present draft, to avoid a
complicated discussion about what updates what when 3484 is replaced. Just
say that the WKP SHOULD have a lower preference than IPv4 in the table.

    Brian

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Dec 2009 20:56:37 +0100

On 23 dec 2009, at 20:38, Brian E Carpenter wrote:

>> removal of all the non-/96 NSP stuff.

> I don't think you've shown consensus for that.

In Hiroshima everyone at the mic was asking for simplicity. What's in the draft now isn't simple.

> Personally, I fear that

I'd rather see people figure this out in practice and then standardize it if that's useful. All of this is internal to a service provider network so there are no interoperability issues that need to be hamered out before experimentation can happen. And nobody except the IVI people has expressed interest in any of this, either.

> What do you mean about referrals?

If the two of us are behind different NAT64s but both use the WKP then I can tell you to connect to 64:ff9b::192.0.2.31 that I'm already talking to and you can actually connect to that address.

> say that the WKP SHOULD have a lower preference than IPv4 in the table.

Ok.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Dec 2009 14:09:37 +1300

> I'd rather see people figure this out in practice and then standardize it if that's useful. All of this is internal to a service provider network so there are no interoperability issues that need t…

It's a matter of taste I guess. The essential thing I believe is to
insist on the u/g bit, and recommending to skip a complete byte
seems to make sense. It's correct that the rest of the detail
could probably be dropped for now without causing interoperability
issues.

People might need to do this if load balancing with the WKP blows up.

> If the two of us are behind different NAT64s but both use the WKP then I can tell you to connect to 64:ff9b::192.0.2.31 that I'm already talking to and you can actually connect to that address.

That will definitely fail if multiple WKPs are used for load balancing
at one site and not the other. I think it will also fail (like 6to4)
if the IPv4 address space fragments some years from now, but that's
going to be a problem anyway.

   Brian