Subject: [BEHAVE] Prefix draft in progress

From: Dave Thaler <[email-masked]>
Date: Thu, 2 Jul 2009 04:58:12 +0000

As mentioned earlier (http://www.ietf.org/mail-archive/web/behave/current/msg06066.html), I took a shot at building a doc from existing drafts/emails with the goal to transition the doc to willing volunteers for the next version.  Dan and I agreed that the initial version would be posted as an individual submission first and then ask the WG whether to adopt it as the WG document in Stockholm.

The draft is still in progress (-00 deadline is next Monday), but since I know there are folks waiting to see what it looks like, I've put a current copy up at:
http://research.microsoft.com/en-us/um/people/dthaler/draft-thaler-behave-translator-addressing-00.txt

I will continue working on it over the next couple of days (although this weekend is a holiday in the US).

-Dave Thaler

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 03 Jul 2009 12:29:10 +0200

Hi,

Overall, i agree with the document the recommendations it makes.

I attach some comments below.

Regards, marcelo

In section 2.1. Requirements

I guess that there is one requirement that you could call 2.1.0 and it 
os failry obvious, that is uniqueness. I mean, in particular, the IPv6 
representation of the IPv4 address must be unique in its scope of 
application (and i guess a similar requriment can be define for the IPv4 
representation of the IPv6 address)
This si the requirement that prevents using the WK prefix with private 
IPv4 addresses in the IPv6 internet. I guess it is very obvious, but i 
guess it is a requirement that needs to be met and the imposes constraints.

Later on, in 2.1.4. Support for Multiple IPv6/IPv4 Translators it reads:

This issue is somewhat orthogonal to the choice of prefix.

Right, but it may be worth to note that it is not orthogonal to the 
algorithm, which is the other issue discussed in this draft.

Later on

2.1.5.2. IPv6 Address Consumption

[EDITOR'S NOTE: This section needs a formulation of what the actual
requirement is, independent of whether the prefix is network-specific
or well-known. I haven't come across such a formulation in any
previous draft yet.]

Is there an issue here? I am not convinced this is a problem, maybe we 
should just drop this one

Later on it reads:

2.1.5.4. EUI-64 Format

The use of a prefix length longer than 64 bits may affect the
Interface Identifier format. [RFC4291] section 2.5.1 requires that
for all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format. While any method can be used
to construct a Modified EUI-64, the format requires the 71st bits
(the universal/local bit) to be set with specific meaning, and hence
they are not available for use by an address format unless the prefix
starts with binary 000.

It is not also the "g" bit that needs to set properly accroding to IPv6 
address architecture format of interface identifiers?

then it reads:

2.2. Network-Specific Prefix

IPv6 prefixes are assigned to a network operator by its regional
internet registrar (RIR).

Well, this is not always the case, small ISPs can get their addressed 
from their transit ISPs
It is a business decision whether to get the addresses directly fromt he 
RIR or get them from a transit provider and both models are widely used 
today afaik

then, the same section reads:

If the network operator is an ISP that has been allocated a /32 or
shorter, then it may be possible for the ISP to allocate a fairly
short prefix such as a /40. However, if the network operator is an
end site with a /48, then the prefix for the translator would be much
longer, such as a /56. Using a /56 prefix still leaves 24 bits that
can be used (without routing on prefixes longer than 80 bits) for
routes via different translators (e.g., in order to access different
parts of the IPv4 network through different translators). However,
since a prefix that originates from an RIR will not start with binary
000, the use of the 71st bit cannot be used by any format with a
network-specific prefix.

wouldn't the "g" bit also be affected here?

Later in section 2.4. Scenario-Specific Discussion and Recommendations

I think it may be interesting to explicitly mention who is running the 
translator. At least in sections 2.4.2 and 2.4.3 i guess it is fairly 
trivial to assume that the translator is run by the guy running the 
(IPv4 or IPv6 depnding on the scenario) network
In scenario 2.4.1 it is hard to say, but since it is out of the scope, 
there is no problem and in scenario 2.4.4, i guess it can be part of 
either the IPv6 or the IPv4 network, but mentioning may be worthy

Section 5.1 reads:

In the first scenario (an IPv6 address assigned to an IPv6 host),
an IPv4 NAT has IPv4 public address Y, and an address translator
uses IPv4 address X to map to an IPv6 address assigned to the
IPv6 host. If the IPv6 host sends an application payload that
includes an IPv6 address that directly embeds X (e.g.,
::ffff:0:X) then this may be translated by the IPv4 NAT to
::ffff:0:Y, and similarly if the IPv4 host sends an application
payload that includes ::ffff:0:Y then this may be translated by
the IPv4 NAT to ::ffff:0:X. This may or may not be desirable.

Thaler Expires January 2, 2010 [Page 11]

Internet-Draft IPv6 Addressing of IPv6/IPv4 Translators July 2009

________
X Y / IPv4 \
IPv6 ---- IPv6/IPv4 ------- "Helpful" ---| Internet |- IPv4
Host Translator IPv4 NAT \________/ Host

In the second scenario (an IPv6 address used for an IPv4 host),
the IPv4 NAT has public address Y, and the IPv4 host behind it
has address Z. If the IPv6 host sends an application payload that
includes an IPv6 address that directly embeds Y (e.g., ::ffff:Y)
then this may be translated by the IPv4 NAT to ::ffff:Z, and
similarly if the IPv4 host sends an application payload that
includes ::ffff:Z then this may be translated by the IPv4 NAT to
::ffff:Y. This may or may not be desirable.

________
/ IPv4 \ Y Z
IPv6 ---- IPv6/IPv4 --| Internet |----- "Helpful" --- IPv4
Host Translator \________/ IPv4 NAT Host

As a result, protocols such as Teredo [RFC4380] and STUN
[RFC5389] today avoid such problems by obscuring the IPv4 address
using XOR.

Note that providing this capability conflicts with requirement 3,
but anything that meets requirement 4 will also meet this
requirement.

I would suggest moving this discussion to an appendix. Seems to be too 
detailed to be included in a section that aims to provide a concise list 
of requirements.

3.2. Mechanisms

I am a bit confused in this section cause there are many well know 
prefixes. I mean, there is the WK prefix defined by this document and 
others alreayd available and it is not clear to me when the document 
talks about the WK prefix defined by this document or the other well 
know prefix or in general about any well know prefix. Maybe it would be 
good to be more clear about that. for instace, in section 3.2.3 talks 
about different well know prefixes and i am not sure when it applies to 
which.

Section 3.2.3. Zero-Pad And Embed reads

Note that typically the dotted-decimal form can only be
used for input and in documentation, but not display since display
would require the PREFIX to be known to all displaying systems to
indicate the use of dotted-decimal.

If the WK prefix is used, it can be used for display, right?

Dave Thaler escribió:
>
> As mentioned earlier 
> (http://www.ietf.org/mail-archive/web/behave/current/msg06066.html), I 
> took a shot at building a doc from existing drafts/emails with the 
> goal to transition the doc to willing volunteers for the next version. 
> Dan and I agreed that the initial version would be posted as an 
> individual submission first and then ask the WG whether to adopt it as 
> the WG document in Stockholm.
>
> The draft is still in progress (-00 deadline is next Monday), but 
> since I know there are folks waiting to see what it looks like, I’ve 
> put a current copy up at:
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Dave Thaler <[email-masked]>
Date: Fri, 3 Jul 2009 17:50:16 +0000

Thanks for the quick review.  Some responses below.

> guess it is a requirement that needs to be met and the imposes

Yep, will add this, thanks.

> algorithm, which is the other issue discussed in this draft.

Sure, it would probably make sense to add this to the list of requirements
for the algorithm.

> should just drop this one

Sounds reasonable to me.  If someone formulates a requirement it
can always be added into the next version of the draft.

> address architecture format of interface identifiers?

Nope.  The "g" bit is only ever mentioned when explaining what an
IEEE EUI-64 is, it's not a required property of a Modified EUI-64.
I talked more about this in my 7/1 email about the
Modified EUI-64 format.

> wouldn't the "g" bit also be affected here?

Nope.  (BTW, I originally thought so too and so had it in the text
when I first put it in, but in adding appropriate references, I
found I was incorrect.  I think it's a common misconception,
as evidenced by RFC 3972 section 4 point 6 for example.)

[...]

> If the WK prefix is used, it can be used for display, right?

Without changing the IPv6 address architecture (RFC 4291 section 2.2),
which would be outside the scope of Behave, you can only use
dotted-decimal in the last 32 bits.  And there are probably things
that depend on this fact now.  That's why 6to4 addresses
don't use dotted-decimal for the embedded IPv4 address even though
6to4 has a WK prefix.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Mon, 6 Jul 2009 18:03:34 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dave Thaler
> Sent: Friday, July 03, 2009 10:50 AM
> To: marcelo bagnulo braun
> Cc: Behave WG
> Subject: Re: [BEHAVE] Prefix draft in progress
>

Actually... this is a requirement for the translation algorithm not
the prefix.  And that section already has:
        An algorithm MUST be one-to-one and reversible.
So isn't this already covered?

> Sure, it would probably make sense to add this to the list of

Added:
  An address format SHOULD provide support for multiple IPv6/IPv4
  translators using different routes advertised into the IPv6
  network (and different routes advertised into the IPv4 network).

> can always be added into the next version of the draft.

Removed as suggested.

> as evidenced by RFC 3972 section 4 point 6 for example.)

No change, see response above.

> don't use dotted-decimal for the embedded IPv4 address even though

No change, see response above.

-Dave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 06 Jul 2009 20:37:43 +0200

Dave Thaler escribió:
>>> I guess that there is one requirement that you could call 2.1.0 and
>>>       
>> it
>>     
>>> os failry obvious, that is uniqueness. I mean, in particular, the
>>>       
>> IPv6
>>     
>>> This si the requirement that prevents using the WK prefix with
>>>       
>> private
>>     
>>> IPv4 addresses in the IPv6 internet. I guess it is very obvious, but
>>>       
>> i
>>     

mmm, well, suppose you use the zero-pad and embed algortihm or the embed 
and zero pad with the WK prefix and private addresses, and the expected 
scope is the IPv6 internet, then it doesn't work, right?
Now you use the same algorithm as described in the draft, while you use 
the LIR prefix and no problems
Now you use the same algorithms, but use the WK prefix and the scope is 
an IPv6 network and again, no problems

So, the algorithms as defined in the draft don't by themselves fullflll 
this requirement
The prefix used and the expected scope is needed to know if the 
requirment is met.
So, i don't think that the algorithms as defined in the draft cover this 
particular aspect.

---

From: Dave Thaler <[email-masked]>
Date: Mon, 6 Jul 2009 19:33:12 +0000

> From: marcelo bagnulo braun [mailto:[email-masked]]
> Sent: Monday, July 06, 2009 11:38 AM
> To: Dave Thaler
> Cc: Behave WG

Agree.  Added this to the prefix requirements as you suggested:

 2.1.6. Uniqueness

  An IPv6 address used for an IPv4 host must be unique
  (i.e., not ambiguously map to multiple possible IPv4 hosts)
  within the IPv6 network that can use that address.
  For example, since private IPv4 addresses can be reused
  within multiple IPv4 networks, an IPv6 network that
  connects to multiple such IPv4 networks cannot rely
  on the IPv4 address itself providing uniqueness.

-Dave