Subject: [BEHAVE] Question on embedded address format in draft-baker-behave-v4v6-framework-02

From: <[email-masked]>
Date: Fri, 3 Apr 2009 08:50:01 +0200

Hi,

--------------------
Quoted from draft-baker-behave-v4v6-framework-02:

bits n..n+31  An embedded IPv4 address.  Except in the case of a 96
bit prefix, this address intentionally straddles the boundary
between [RFC4291]'s 64 bit "subnet" locator and its 64 bit host
identifier.  The intention is that the /64 be used in routing and
the bits in the host part be used for host identification as
described in the address architecture.

----------------
RFC4291 says:

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.

-------------
This is taken into account, for instance, in Teredo addresses, quoted
from RFC4380:

The IPv6 addressing rules specify that "for all unicast addresses,
   except those that start with binary value 000, Interface IDs are
   required to be 64 bits long and to be constructed in Modified EUI-64
   format".  This dictates the encoding of the flags, 16 intermediate
   bits that should correspond to valid values of the most significant
   16 bits of a Modified EUI-64 ID:

          0       0 0       1
         |0       7 8       5
         +----+----+----+----+
         |Czzz|zzUG|zzzz|zzzz|
         +----+----+----+----+

   In this format:

   -  The bits "UG" should be set to the value "00", indicating a non-
      global unicast identifier;
   -  The bit "C" (cone) should be set to 1 if the client believes it is
      behind a cone NAT, to 0 otherwise; these values determine
      different server behavior during the qualification procedure, as
      specified in Section 5.2.1, as well as different bubble processing
      by clients and relays.
   -  The bits indicated with "z" must be set to zero and ignored on
      receipt.

   Thus, there are two currently specified values of the Flags field:
   "0x0000" (all null) if the cone bit is set to 0, and "0x8000" if the
   cone bit is set to 1.  (Further versions of this specification may
   assign new values to the reserved bits.)

---------
Question:

Do we have to address the conformity to Modified EUI-64 format for v4v6
addresses?
In particular the so-called UG bits?
In that case, is it still possible to have an IPv4 embedded address that
crosses the 64bit boundary?
If we do not care, why does Teredo (which includes two IPv4 addresses)
care?

Regards

Pierre

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Apr 2009 11:43:17 +1200

> Hi,

...
> In particular the so-called UG bits?

Yes, I think we should.

> crosses the 64bit boundary?

I don't see why not, as long as we stuff the UG bits in at the
appropriate bit positions.

   Brian

---

From: <[email-masked]>
Date: Tue, 7 Apr 2009 08:58:27 +0200

Yes, but that means routers will have to remove these two bits before processing the routing information. That can be pretty tricky, mainly if we allow LIR Prefixes whose length will vary from one provider to another (even if the UG bits are always at the same place).

Shouldn't this issue be mentionned in draft-baker-behave-v4v6-framework-02?

 Pierre

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Brian E Carpenter
Envoyé : lundi 6 avril 2009 01:43
À : LEVIS Pierre RD-CORE-CAE
Cc : [email-masked]
Objet : Re: [BEHAVE] Question on embedded address format indraft-baker-behave-v4v6-framework-02

...

Yes, I think we should.

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 7 Apr 2009 09:33:50 -0700

On Apr 2, 2009, at 11:50 PM, <[email-masked]> <[email-masked] 
 > wrote:

> Do we have to address the conformity to Modified EUI-64 format for  
> v4v6 addresses? In particular the so-called UG bits? In that case,  
> is it still possible to have an IPv4 embedded address that crosses  
> the 64bit boundary? If we do not care, why does Teredo (which  
> includes two IPv4 addresses) care?

The CERNET prototype hasn't had any issues with ignoring them.

Section 2.5.1 of RFC 4291 goes to some lengths to say two things. The  
first is that an interface identifier has to be unique on the LAN-or- 
whatever it is on. The second is that when the interface identifier is  
a MAC address it should be in a format related to a MAC Address -  
except that it is different.

    Modified EUI-64 format-based interface identifiers may have  
universal
    scope when derived from a universal token (e.g., IEEE 802 48-bit MAC
    or IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
    global token is not available (e.g., serial links, tunnel end- 
points)
    or where global tokens are undesirable (e.g., temporary tokens for
    privacy [PRIV]).

    Modified EUI-64 format interface identifiers are formed by inverting
    the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
    forming the interface identifier from IEEE EUI-64 identifiers.  In
    the resulting Modified EUI-64 format, the "u" bit is set to one (1)
    to indicate universal scope, and it is set to zero (0) to indicate
    local scope.

So, especially given privacy addressing, we can't really assume that  
the router or neighboring host is going to extract a MAC address from  
the interface identifier and directly use it to direct a datagram to  
another host; rather, the relationship between a MAC address and an  
interface identifier has a level of indirection managed by Neighbor  
Discovery.

Given that the address architecture specifies the bits but only uses  
them to ensure that the interface identifier is not "all zeroes" and  
is unique, and in this context the addresses are in fact unique, my  
sense would be to ignore the question.

That said, the fact should probably be explained in the prefix document.

Other thoughts?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 7 Apr 2009 23:11:00 +0200

On 7 apr 2009, at 18:33, Fred Baker wrote:

>> v4v6 addresses? In particular the so-called UG bits?

> The CERNET prototype hasn't had any issues with ignoring them.

There could still be trouble down the road, the point of  
specifications is that two or more people follow them.

> the router or neighboring host is going to extract a MAC address  
> from the interface identifier and directly use it to direct a  
> datagram to another host;

Right. But then, nobody is suggesting that.

> sense would be to ignore the question.

What we lose in that case is the possibility of recognizing a certain  
class of addresses just by looking at the interface identifier. That  
is not something we have any use for today, but we might in the future.

By coincidence we ended up in the situation that it's as good as  
impossible to have an interface identifier with 11 in the two lower  
bits of the upper byte (u/l = unique, group = yes) because only  
stateless autoconfig and other eui-64 derived configuration set the u/ 
l bit to unique, but since it doesn't make sense to create a unicast  
network address from a multicast link address, the g bit is always 0  
in that case.

So if we ever find a use for being able to recognize a special class  
of interface identifiers we could use the unique/group combination for  
those and have only a minimal chance of clashing with other address  
types. It would be a shame to throw away this possibility without a  
good reason.

---

From: Rémi Després <[email-masked]>
Date: Wed, 08 Apr 2009 11:50:12 +0200

Fred Baker  -  le (m/j/a) 4/7/09 6:33 PM:
> 
> On Apr 2, 2009, at 11:50 PM, <[email-masked]> 
> <[email-masked]> wrote:
> 
>> v4v6 addresses? In particular the so-called UG bits? In that case, is 
>> it still possible to have an IPv4 embedded address that crosses the 
>> 64bit boundary? If we do not care, why does Teredo (which includes two 
>> IPv4 addresses) care?
> 

> Other thoughts?

If I understand it right, distinguishing between EUI-64 and local-scope 
identifiers IS necessary where subnet prefixes are /64, but ONLY in this 
case.

A node outside a destination subnet is not expected to make any
assumption on the length of this subnet prefix.

Thus, extension of prefixes beyond /64 can be done freely, without
concern with a rule for links where subnet prefixes are /64.

As a matter of fact, this reasoning has been important to significantly 
simplify draft-despres-sam-xx between versions 01 and 02.

Regards,

RD

---

From: Fred Baker <[email-masked]>
Date: Wed, 8 Apr 2009 10:23:21 -0700

On Apr 7, 2009, at 2:11 PM, Iljitsch van Beijnum wrote:

>> So, especially given privacy addressing, we can't really assume  
>> that the router or neighboring host is going to extract a MAC  
>> address from the interface identifier and directly use it to direct  
>> a datagram to another host;
>
>> Given that the address architecture specifies the bits but only  
>> uses them to ensure that the interface identifier is not "all  
>> zeroes" and is unique, and in this context the addresses are in  
>> fact unique, my sense would be to ignore the question.
>
> What we lose in that case is the possibility of recognizing a  
> certain class of addresses just by looking at the interface  
> identifier. That is not something we have any use for today, but we  
> might in the future.

Perhaps. We haven't needed it in IP, apart from the fairly ancient  
notion of using all ones in the host identifier to generate a local  
subnet broadcast. For security reasons, that has been deprecated, and  
IPv6 uses a different format for such things.

> stateless autoconfig and other eui-64 derived configuration set the  
> u/l bit to unique, but since it doesn't make sense to create a  
> unicast network address from a multicast link address, the g bit is  
> always 0 in that case.
>
> of interface identifiers we could use the unique/group combination  
> for those and have only a minimal chance of clashing with other  
> address types. It would be a shame to throw away this possibility  
> without a good reason.

Well, yes. But I think at least part of the question Pierre asked was  
- if we don't have a particularly good reason to worry about it, why  
specifically is Teredo worried about it?

You have heard the famous Einstein quip, that one is done describing  
something not when everything has been included, but when everything  
unnecessary has been carted away. If one is using a MAC address as a  
MAC address, as I alluded to above, including the flags in the MAC  
address that it defines makes a lot of sense. If one is not and there  
is no well-understood reason to include the issue, why break bones  
worrying about it?

I'll step away from the posiiton if someone can give me a good reason,  
but at this point I don't see one.

---

From: Fred Baker <[email-masked]>
Date: Wed, 8 Apr 2009 10:28:00 -0700

Let me restate what I think you said in my words. If I get it wrong, I  
missed you.

I think you are arguing that an IPv6 address is first and foremost a  
CIDR address - routers have some knowledge of prefix lengths due to  
their advertisement in routing protocols, and hosts on a LAN know  
something about the local LAN's prefix length because if the  
assumptions built into the handling of an address - SLAAC Really Wants  
the prefix to be a /64, but DHCP is essentially assigning a /128 and  
the host doesn't need to understand the big picture of the rules as  
long as it accepts any /128 from any immediate neighbor, and other  
mechanisms are like DHCP in that regard. So apart from CIDR rules and  
SLAAC assumptions in address prefixes governed by SLAAC, nobody should  
make any assumptions.

Did I get that right?

On Apr 8, 2009, at 2:50 AM, Rémi Després wrote:

> If I understand it right, distinguishing between EUI-64 and local- 
> scope identifiers IS necessary where subnet prefixes are /64, but  
> ONLY in this case.
>
> As a matter of fact, this reasoning has been important to  
> significantly simplify draft-despres-sam-xx between versions 01 and  
> 02.
>
> Regards,
>
> RD
>
>

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Apr 2009 16:15:18 +0200

Fred Baker  -  le (m/j/a) 4/8/09 7:28 PM:
> their advertisement in routing protocols,
In routers that have no direct interface with source or destination
links, an IPv6 address is processed according to the CIDR logic, yes.

(*) In routers that have direct interfaces to source or destination links,
there are two cases:
(A) If the address space on the link is global, the rule 64-bit-IID rule
applies to global addresses.
(B) If global packets are locally encapsulated, this rule doesn't need
to apply to global addresses.

> and hosts on a LAN know 
> something about the local LAN's prefix length because if the assumptions 
> built into the handling of an address

With RS and RAs, exchanged in the link-local address space, hosts know
link subnet prefix lengths independently of their global addresses.

> - SLAAC Really Wants the prefix to 
> be a /64,

For IIDs that are modified EUI-64, a /64 prefix is indeed needed.

(**) But, unless I miss something, this constraint could be relaxed for 
local scope IIDs if found useful for some new function.

> ... So apart from CIDR rules and SLAAC assumptions in 
> address prefixes governed by SLAAC, nobody should make any assumptions.

No assumption on formats in fields that are not processed locally.

> Did I get that right?

I think so.

Points (*) and (**) go beyond what was said previously.

Regards,

RD

>> If I understand it right, distinguishing between EUI-64 and 
>> local-scope identifiers IS necessary where subnet prefixes are /64, 
>> but ONLY in this case.
>>
>> significantly simplify draft-despres-sam-xx between versions 01 and 02.
>>
>> Regards,
>>
>> RD
>>
>>
> 
>

---

From: <[email-masked]>
Date: Thu, 16 Apr 2009 14:17:45 +0200

To summarize this thread:

Issue: In v4v6 addresses (v4 address embedded into v6 address), the v4 address may straddle the 64-bit boundary
Do we have to worry about the conformity to Modified EUI-64 format? In particular the so-called UG bits?

We can take care of the UG bits, stuffing a byte after the first 64-bit part, the v4v6 address will then be:
<Prefix, beginning of v4 address, stuffed byte, end of v4 address, suffix>
The prefix to route is: <Prefix, beginning of v4 address, stuffed byte, end of v4 address> which looks queer but should work

If we do not care of the UG bits, we lose the possibility of recognizing a certain class of addresses just by looking at the interface identifier. 
However, no use today.

If we look at RFC4291, we see that even if v4v6 addresses are indeed unicast addresses, they are not really in the scope, this 64-bit boundary does not really make sense here:
"Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet prefix."
"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."

So, I tend to agree that for v4v6 addresses we should not care of this Modified EUI-64 format.

Pierre

-----Message d'origine-----
De : Rémi Després [mailto:[email-masked]] 
Envoyé : vendredi 10 avril 2009 16:15
À : Fred Baker
Cc : LEVIS Pierre RD-CORE-CAE; Xing Li; Behave WG
Objet : Re: [BEHAVE] Question on embedded address format in draft-baker-behave-v4v6-framework-02

I think so.

Regards,

RD

---

From: <[email-masked]>
Date: Fri, 17 Apr 2009 08:30:58 +0200

Yes if we read RFC4291 this way: 
"For all unicast addresses, except those that start with the binary value 000, Interface IDs are required [...]to be constructed in Modified EUI-64 format."
it should!

But if we read RFC4291 that way:
"Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet prefix."
"For all unicast addresses, except those that start with the binary value 000, Interface IDs are required [...] to be 64 bits long"
That means too:
A v4v6 address <Prefix,IPv4 Address,Suffix> with the IPv4 address that crosses the 64-bit boundary should be interpreted as:
<Prefix,IPv4 Ad> is the Network Prefix, it is 64-bit long 
<dress,Suffix> is the IID, it is 64-bit long, it identifies an interface, and it is unique within <Prefix,IPv4 Ad>
Which is obviously not the case here!

So, as far as I understand, if we want to fully follow RFC4291, the only possibility is that Prefix is a IANA prefix, and that it begins with 000

Did I miss something?

Pierre 

-----Message d'origine-----
De : Brian E Carpenter [mailto:[email-masked]] 
Envoyé : vendredi 17 avril 2009 01:52
À : LEVIS Pierre RD-CORE-CAE
Objet : Re: [BEHAVE] Question on embedded address format in draft-baker-behave-v4v6-framework-02

On 2009-04-17 00:17, [email-masked] wrote:
...
> So, I tend to agree that for v4v6 addresses we should not care of this Modified EUI-64 format.

For addresses that start with binary 000 only. But for anything under an LIR prefix,
the EUI-64 requirement applies.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Fri, 17 Apr 2009 11:42:40 -0400

> Did I miss something?

besides that an unroutable prefix makes translation a real pain in the  
network, which is why deployed translators (including both CERNET's  
IVI and many NAT-PT deployments) use anything but the magic prefix  
model that this working group so strongly likes?

No, nothing at all.

On Apr 17, 2009, at 2:30 AM, <[email-masked]> wrote:

> "For all unicast addresses, except those that start with the binary  
> value 000, Interface IDs are required [...]to be constructed in  
> Modified EUI-64 format."
> it should!
>
> "Interface identifiers in IPv6 unicast addresses are used to  
> identify interfaces on a link. They are required to be unique within  
> a subnet prefix."
> "For all unicast addresses, except those that start with the binary  
> value 000, Interface IDs are required [...] to be 64 bits long"
> That means too:
> A v4v6 address <Prefix,IPv4 Address,Suffix> with the IPv4 address  
> that crosses the 64-bit boundary should be interpreted as:
> <dress,Suffix> is the IID, it is 64-bit long, it identifies an  
> interface, and it is unique within <Prefix,IPv4 Ad>
> So, as far as I understand, if we want to fully follow RFC4291, the  
> only possibility is that Prefix is a IANA prefix, and that it begins  
> with 000
>
> Did I miss something?
>
> Pierre
>
>> If we look at RFC4291, we see that even if v4v6 addresses are  
>> indeed unicast addresses, they are not really in the scope, this 64- 
>> bit boundary does not really make sense here:
>> "Interface identifiers in IPv6 unicast addresses are used to  
>> identify interfaces on a link. They are required to be unique  
>> within a subnet prefix."
>> "For all unicast addresses, except those that start with the binary  
>> constructed in Modified EUI-64 format."
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 17 Apr 2009 20:52:09 +0200

> model that this working group so strongly likes?
maybe the reason why current NATPT doesn't use the WK prefix it is 
beacuse the WK prefix was not defined before and the NATPT spec ony 
defined the use of the now called LIR prefix?

>> "Interface identifiers in IPv6 unicast addresses are used to identify 
>> interfaces on a link. They are required to be unique within a subnet 
>> prefix."
>>> If we look at RFC4291, we see that even if v4v6 addresses are indeed 
>>> unicast addresses, they are not really in the scope, this 64-bit 
>>> boundary does not really make sense here:

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Apr 2009 13:30:04 +1200

> defined the use of the now called LIR prefix?

Well, SIIT defines the IPv4-mapped prefix (::ffff/96), which is a WKP
if I ever saw one. NAT-PT says nothing to forbid using it as the PREFIX.
Actually it says you can use whatever you want. Of course, SIIT is very
clear that IPv4-mapped prefixes should never appear in IPv6 routing.

   Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 21 Apr 2009 10:03:41 +0200

> clear that IPv4-mapped prefixes should never appear in IPv6 routing.

but according to our tests, IPv6 implementations never use this prefix 
on the wire, it is only used to represent IPv4 addresses as IPv6 for 
issues internal to the host (like comparing v4 and v6 addresses in the 
rfc3484 selection rules)

so, if you ask a node to send a packet to this address, it will send an 
IPv4 packet if it can, and if not, it won't send anything (i.e. it will 
never use this address in the wire)

So, this prefix doesn't really works for NATPT, since, the hosts will 
never generate an IPv6 packet with this prefix.

Regards, marcelo

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Apr 2009 16:20:55 +0200

> clear that IPv4-mapped prefixes should never appear in IPv6 routing.

In January 2008, there was a v6ops discussion on the subject, but AFAIK 
without conclusion.

IMHO ::ffff/96 is the natural choice for a /96 WKP for IPv4 in IPv6 
embedded addresses: it already exists, and has all what is needed.

In my understanding, none of the reasons discussed in "IPv4-Mapped 
Addresses on the Wire Considered Harmful" applies to use cases of NAT64s.

(This is of course NOT to say that a /96 WKP should be the ONLY way to 
map an IPv4 address in an IPv6 address. Many other can exist, in 
particular with port-extended IPv4 addresses, with SAM etc.)

Regards,

RD

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Apr 2009 10:25:20 -0400

> embedded addresses: it already exists, and has all what is needed.

Disagree.  That prefix was specifically NOT intended to ever be used on
the wire.

> Addresses on the Wire Considered Harmful" applies to use cases of NAT64s.

It really doesn't matter.  That decision was made long ago.  There's too
much deployed code out there now that assumes that these addresses
should not be used on the wire.

IMO, we'd be better off without any WKP than to try to use that one.

Keith

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Apr 2009 16:46:47 +0200

Keith,

I haven't when and where the

Keith Moore  -  le (m/j/a) 4/21/09 4:25 PM:
> Disagree.
> That prefix was specifically NOT intended to ever be used on
> the wire.

Sure, when it was specified, but then dual stack was the rule, and NAT64 
not even at the horizon.

> It really doesn't matter.
Different view.

>  That decision was made long ago. 
Pointing to the RFC that says it would help.

> There's too
Could you be more specific?
(Which code, and serving which purpose?)
> IMO, we'd be better off without any WKP than to try to use that one.
Different view so far.
We need explicit and good reasons to have 2 values where 1 appears to be 
enough.

Regards,
RD

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 21 Apr 2009 17:24:42 +0200

Rémi Després escribió:
> In January 2008, there was a v6ops discussion on the subject, but 
> AFAIK without conclusion.
>
the problem is that current IPv6 implementations do use this prefix in 
the wire, so if they receive a synthetic AAAA RR with this prefix they 
will send an IPv4 packet if they can but they will NOt send an IPv6 
packet with that prefix in the destination address. so this is a non 
starter for this reason.

It would be possible to use the IPv4 compatible prefix, but, the problem 
if we use that is that with current rfc3484 default policy table, the 
translated connectivity is preferred over the native v4 connecitivty, 
which is an issue

hence, imho it is better to use a new prefix for this

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 21 Apr 2009 17:26:30 +0200

> should not be used on the wire.
agree

we tested it and implementation do not send IPv6 packet with this 
prefix, so this is a non starter

we need a new prefix allocated by iana
if we ask for a prefix, we can get a prefix so that the longest prefix 
match rule in rfc3484 help us to preffer nartive connectivity over 
translated connectivity.

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 21 Apr 2009 17:29:36 +0200

Rémi Després escribió:
> Sure, when it was specified, but then dual stack was the rule, and 
> NAT64 not even at the horizon.
>
we tried windows (several flavors) linux and a couple of nokia phones.

the result always the same, no IPv6 packets generated using that prefix

regards, marcelo

> We need explicit and good reasons to have 2 values where 1 appears to 
> be enough.
>
>
> Regards,
> RD

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Apr 2009 14:48:39 -0400

> We need explicit and good reasons to have 2 values where 1 appears to be

No, we need explicit and good reasons to change the addressing
architecture.  None have been given.

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Apr 2009 09:08:32 +0200

Keith Moore  -  le (m/j/a) 4/21/09 8:48 PM:
> No,
I suppose you don't really mean NO to this statement?

> we need explicit and good reasons to change the addressing
> architecture.
YES.

> None have been given.

None has been given BECAUSE it is not clear, so far, that if we use the 
existing well known prefix ::FFFF:0:0/96 of IPv4 mapped addresses, 
rather than defining a new one, any RFC is offended.

Pointing to an existing rule that forbids to use this prefix on the wire 
(if  it exists) would help clarifying this debate.

Regards,

RD

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 22 Apr 2009 10:31:05 +0200

On 22 apr 2009, at 9:08, Rémi Després wrote:

> None has been given BECAUSE it is not clear, so far, that if we use  
> the existing well known prefix ::FFFF:0:0/96 of IPv4 mapped  
> addresses, rather than defining a new one, any RFC is offended.

Well then, why don't we simply deprecate RFC 791 and point people  
towards RFC 2460 and the whole mess is solved?

Oh wait, that's not operationally feasible?

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 22 Apr 2009 10:52:42 +0200

Rémi Després escribió:
> the existing well known prefix ::FFFF:0:0/96 of IPv4 mapped addresses, 
> Pointing to an existing rule that forbids to use this prefix on the 
> wire (if  it exists) would help clarifying this debate.

sigh, let me try one more time
We tried to use this prefix in current implementations and they do not 
use this prefix in the wire.
If we use this prefix we need to change the implementations, beating one 
of the key goals, which is to support unchanged IPv6 hosts

So, it is a non starter, really.

(BTW, we took the trouble of testing this because we would have liked 
very much to be able to use it, but unfortunatelly, we can't)

Regards, marcelo

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Apr 2009 15:15:52 +0200

marcelo bagnulo braun  -  le (m/j/a) 4/22/09 10:52 AM:

> Rémi Després escribió:
>> it is not clear, so far, that if we use 

OK, I get the point that tests you made showed that at least current 
implementations you tested couldn't work with the mapped address prefix 
used to reach NAT64s.

I also get the point that, with a different WKP, there would have been a 
very good chance that these same implementations could have worked.

The short term and easy conclusion seems then to be the definition of a 
new WKP.
But ALL CONSEQUENCES of having two ways to do essentially the same thing 
have to be anticipated.

Here is an example of a POSSIBLE PROBLEM (there may be others):
- An application that is both IPv4 and IPv6 capable is run in an 
IPv6-only host.
- It gets an A RR in response to a DNS query (obtained in IPv6).
- Then it presents the received IPv4 address at its PF_INET6 socket 
interface in mapped format, conforming in this to RFC2553 sec 3.7.
- If the stack is not capable to forward IPv6 packets with this 
destination address, connectivity is lost.

Of course, applications could be changed, e.g. to detect the lost 
connectivity and next try the other WKP, but is this to be suggested 
rather than fixing IPv6 stacks?

Please be sure that this discussion is not just for the sake of arguing. 
I may be wrong in this particular case, but I believe there may be 
significant operational consequences ahead when an existing 
specification, without being deprecated, is proposed to coexist with a 
new one to do the same thing.

Regards,

RD

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 22 Apr 2009 15:36:11 +0200

Rémi Després escribió:
>>> it is not clear, so far, that if we use the existing well known 
>>> prefix ::FFFF:0:0/96 of IPv4 mapped addresses, rather than defining 
>>> a new one, any RFC is offended.
>>>
>> We tried to use this prefix in current implementations and they do 
>> not use this prefix in the wire.
>> If we use this prefix we need to change the implementations, beating 
>> one of the key goals, which is to support unchanged IPv6 hosts
>>
> implementations you tested couldn't work with the mapped address 
> prefix used to reach NAT64s.
>
> I also get the point that, with a different WKP, there would have been 
> a very good chance that these same implementations could have worked.
>

good!
> The short term and easy conclusion seems then to be the definition of 
> a new WKP.
> But ALL CONSEQUENCES of having two ways to do essentially the same 
> thing have to be anticipated.
>
i certainly agree with that

> destination address, connectivity is lost.
right, so what is the problem? I mean, in ths scenario it seems we have 
an IPv6 only host that is trying to communicate to an IPv4 only host and 
hast no NAT64 available (it there were, it would had received a 
synthetic AAAA RR containing either the WK prefix or the LIR prefix 
being used by the nat64 box and the communication would have been 
established)

So, i am missing why is this a problem if there is a nat64 and if there 
is a nat64 what are the problems that srping from having the WK prefix 
being different from the IPv4 mapped prefix (i am sure you had something 
in mind, just not clear to me from this example you provided)

> rather than fixing IPv6 stacks?
no, we asume that in ortder to make this work, we need to use a dns64

> Please be sure that this discussion is not just for the sake of arguing
i know
i certainly don't think so

> . I may be wrong in this particular case, but I believe there may be 
but they are not doing the same thing, since the v4 mapped is not 
supposed to be in the wire.
I  don't know if there is any rfc that says so, but this is the current 
practice.

Regards, marcelo

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Apr 2009 19:12:55 +0200

> in mind, just not clear to me from this example you provided)

OK, I understand the answer and, after the comment below, have no plan 
to  insist.

In my understanding, the following constraints result from the fact that 
IPv4 mapped addresses have been artificially excluded from valid 
destinations in IPv6-only environments:
- IPv6-only hosts MUST send ONLY recursive queries (as most host do, but 
so far without being obliged to).
- If these queries are not sent directly to DNS64 servers at 
v6only-v4only borders, intermediate servers MUST:
   . NOT be in dual stack clouds (there, they should not loose the 
ability to respond with As).
   . NOT handle recursive queries by themselves (although they typically 
do it)
   . instead, forward recursive queries to a v4-v6 border server, or to 
  intermediate servers having the same constraints.

These may not be the exact constraints, but should be close to reality.

If on the contrary mapped addresses would not have been artificially 
barred, and would have remained the ONLY way to express a v4 address in 
v6 format:
- The constraint above on DNSs would have not been needed.
- IPv4-only servers would have become accessible via NAT64s by IPv6-only 
applications, and by dual-stack applications in v6-only hosts, just by 
having their mapped addresses in AAAA RRs in their local DNSs.
- Compatibility between on the fly RR translations and DNSsec would NOT 
have been a problem.

Well, the past is the past, that's life :-(.

To be optimistic, that's one more reason to make IPv6 deployment 
everywhere as rapid as possible ;-).

Regards,

RD

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 22 Apr 2009 21:26:21 +0200

Rémi Després escribió:
>> right, so what is the problem? I mean, in ths scenario it seems we 
>> have an IPv6 only host that is trying to communicate to an IPv4 only 
>> host and hast no NAT64 available (it there were, it would had 
>> received a synthetic AAAA RR containing either the WK prefix or the 
>> LIR prefix being used by the nat64 box and the communication would 
>> have been established)
>>
>> So, i am missing why is this a problem if there is a nat64 and if 
>> there is a nat64 what are the problems that srping from having the WK 
>> prefix being different from the IPv4 mapped prefix (i am sure you had 
>> something in mind, just not clear to me from this example you provided)
>
> In my understanding, the following constraints result from the fact 
> that IPv4 mapped addresses have been artificially excluded from valid 
> - IPv6-only hosts MUST send ONLY recursive queries (as most host do, 
> but so far without being obliged to).
well, they can implement DNS64 in the local resolver, in whcih case they 
can do non recursive and synthesis locally (that requires host changes 
indeed)

> ability to respond with As).
don't understnad this one,could you expand?

>   . NOT handle recursive queries by themselves (although they 
> typically do it)
not sure what scenario do you have in mind... areyou talking about a dns 
server running in a v6 only machine? If so, why it cannot handle 
recursive lookups? cause the lack of native v4 transport? If so why this 
is related to DNS64?

> barred, and would have remained the ONLY way to express a v4 address 
> in v6 format:
> - IPv4-only servers would have become accessible via NAT64s by 
> IPv6-only applications, and by dual-stack applications in v6-only 
> hosts, just by having their mapped addresses in AAAA RRs in their 
> local DNSs.
> - Compatibility between on the fly RR translations and DNSsec would 
> NOT have been a problem.
>
i think i agree with the last two at least
but i think this was possible world that turns out not to be the one we 
are currently living (in other words, it would have been cool to have 
that, but we don't, i guess)

> Well, the past is the past, that's life :-(.
ditto

Regards, marcelo

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Apr 2009 11:20:30 +0200

marcelo bagnulo braun  -  le (m/j/a) 4/22/09 9:26 PM:
> don't understnad this one,could you expand
> 

1.
I was assuming that the local DNS was not capable to do the translation.
But that may not be worth considering further.

The constraint is then limited to what has already been written, namely 
if I am right:
A. in the IPv6-network-to-IPv4-Internet case, hosts must send recursive 
queries ONLY to DNS64-capable DNS servers.
B. in the IPv6-Internet-to-an-IPv4-network case, "the DNS64 function is 
provided by the end site itself".

2.
BTW, if not done yet, and if I am not mistaken, it's worth noting that 
if DNSs of IPv4-only servers are populated, by hand or by other means, 
with AAAAs containing the agreed WKP and their IPv4 addresses (in 
addition to their As), then these servers become accessible via NAT64s 
*independently of DNS64-capable servers existing anywhere, and with 
IPsec compatibility*.

I don't see which harm a recommendation to do this could do, and the 
benefit can be quite substantial.

With it, agreeing on a WKP becomes even more urgent.

Regards,

RD

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Apr 2009 11:58:12 +0200

Rémi Després escribió:
>>> that IPv4 mapped addresses have been artificially excluded from 
>>> valid destinations in IPv6-only environments:
>> well, they can implement DNS64 in the local resolver, in whcih case 
>> they can do non recursive and synthesis locally (that requires host 
>> changes indeed)
>>
>> not sure what scenario do you have in mind... areyou talking about a 
>> dns server running in a v6 only machine? If so, why it cannot handle 
>> recursive lookups? cause the lack of native v4 transport? If so why 
>> this is related to DNS64?
>
> 1.
> The constraint is then limited to what has already been written, 
> namely if I am right:
> A. in the IPv6-network-to-IPv4-Internet case, hosts must send 
> recursive queries ONLY to DNS64-capable DNS servers.
this works fine
i think it also works fine with DNS forwarders as long it ends up 
querying a dns64 capable recursive server wihtin the site
the main limitation as i see it, is that the dns64 and the nat64 must be 
operated by the same admin domain (or must coordiante the prefix64 they 
will use)

>
> B. in the IPv6-Internet-to-an-IPv4-network case, "the DNS64 function 
> is provided by the end site itself".
>
no, this case can works fine even wihtou a dns64 function (and this is 
the reccomended appraoch actually)
there is a lengthy description of this case in the dns64 draft

> *independently of DNS64-capable servers existing anywhere,

right

> and with IPsec compatibility*.
>
i am not sure i understnad this one

agree

Regards, marcelo

---

From: Rémi Després <[email-masked]>
Date: Fri, 24 Apr 2009 17:06:06 +0200

Marcello,

Thanks for your answers.
This discussion has been clarifying and IMHO useful.

Some more comments, and answer to your question below.

Regards,

RD

marcelo bagnulo braun  -  le (m/j/a) 4/23/09 4:27 PM:
> Rémi Després escribió:
>> marcelo bagnulo braun  -  le (m/j/a) 4/23/09 11:58 AM:
>>> Rémi Després escribió:
>>
>>> the main limitation as i see it, is that the dns64 and the nat64 must 
>>> be operated by the same admin domain (or must coordiante the prefix64 
>>> they will use)
>>
>> Agreed.
>>
>>> no, this case can works fine even wihtou a dns64 function (and this 
>>> is the reccomended appraoch actually)
>> OK.
>> I was confused by the overview section which says (asterisks added):
>>
>> "The other possible setup that is expected is an IPv4 site that
>>  wants that its IPv4 servers to be reachable from the IPv6
>>  Internet. (This case is called IPv6-Internet-to-an-IPv4-network).
>>  It should be noted that the IPv4 addresses used in the IPv4 site
>>  can be either public or private.  *In this case*, the NAT64 is used
>>  to connect the IPv4 end site to the IPv6 Internet and *the DNS64
>>  function is provided by the end site itself*."
>>
>> Some caveat would IMHO be appropriate here.
> right, this is a convoluted issue
> The reccomended approahc is that in this case, real AAAA RR are 
> published with the IPv6 representation of the IPv4 address.
> Howver, in order to support DynDNS, we may need to use dns64 to 
> dynamically create AAAA RR
> So, while it is not needed and not even reccomended. it may be used and 
> if used the dns64 function will be provided by the end site itself.
>>
>>
>> Also , the title of sec. 1.2.3 of the DNS64 draft could be clearer: 
>> being "IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server 
>> mode", it doesn't suggest that, as the section explains, no DNS64 is 
>> needed.
> 
> is not reccomended, but may be used to support some operational needs
> I will try to clarify this
>>
>> Note that in this section, the DNS server of the IPv4-only server is 
>> still presented as having to synthesize AAAAs (either when receiving 
>> DynDNS updates or when receiving AAAA queries), although it can also 
>> work without it for all hosts in which DynDNS clients would have been 
>> upgraded to also update AAAAs with the WKP when they update As.
>>
> right, this would be a third approach, indeed
> 
>> Upgrades of downloadable DynDNS client applications can of course be 
>> deployed much more rapidly than upgrades of DNS servers (and without 
>> conflicting  with them when also deployed).
>>
> mmm, good point, i agree with that
> 
>> What about adding a note explaining this in the draft?
>>
> yes that make sense to me, at least to also present the case (note that 
> it is not about dns64, but still, i agree it is worth including it)
> 
> I will be making a complete review of the dns64 draft shortly.
> 
>>>> 2.
>>>> BTW, if not done yet, and if I am not mistaken, it's worth noting 
>>>> that if DNSs of IPv4-only servers are populated, by hand or by other 
>>>> means, with AAAAs containing the agreed WKP and their IPv4 addresses 
>>>> (in addition to their As), then these servers become accessible via 
>>>> NAT64s *independently of DNS64-capable servers existing anywhere,
>>>
>>> right
>>>
>> OOPS, I meant "DNSsec compatibility" (sorry).
>>
> agree
> 
>> Sec. 1.2.3 of the DNS64 draft is close to cover this remark in the 
>> IPv6-Internet-to-an-IPv4-network case (cf comment above).
>>
>> It would IMHO be worth noting in the DNS64 draft that this remark also 
>> applies to the an-IPv6-network-to-IPv4-Internet case.
>>
>> (ALL IPv4-only servers for which AAAAs with the WKP are updated in 
>> their DNSs, e.g. by DynDNS clients upgraded for this, are reachable by 
>> ALL IPv6-only hosts having WKP routes to NAT64s on their paths toward 
>> the IPv4 Internet. This doesn't depend on any DNS64 upgrade having 
>> been done in any DNS server).
>>
> right
> i don't know if i want to go there, not at least until we have the WK 
> prefix defined.

IMHO, this remark is by itself an INCENTIVE to have a WKP asap. As soon 
there is one defined, DynDNS clients of IPv4-only servers can be 
upgraded to produce synthetic AAAAs and send them to existing DNS 
servers. The end result is that these servers become immediately 
accessible by IPv6-only clients whose NAT64s are configured with this 
prefix.

I am not sure about the implications of what you propose
> (i think it would be good, but clearly there is much less control of the 
> deployment), espcially in the global routing

I don't see how this use case would have any implication on global 
routing: in my understanding, packets from IPv6-only sources reach their 
NAT64s via routes to the rest of the world (::/0).
> 
> So, i would suggest we discuss this once we have managed to have a more 
> solid agreement on defining the WK prefix, makes sense?

Yes.
Let's then have this agreement quickly.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 24 Apr 2009 23:36:21 +0200

On 24 apr 2009, at 17:06, Rémi Després wrote:

>> i don't know if i want to go there, not at least until we have the  
>> WK prefix defined.

> IMHO, this remark is by itself an INCENTIVE to have a WKP asap. As  
> soon there is one defined, DynDNS clients of IPv4-only servers can  
> be upgraded to produce synthetic AAAAs and send them to existing DNS  
> accessible by IPv6-only clients whose NAT64s are configured with  
> this prefix.

So you want to create synthetic AAAA records at the source (the  
authoritative DNS server) and trust that there wil be a translator  
somewhere that will provide connectivity for those AAAA addresses to  
IPv6 hosts.

This is not a good idea. The translators aren't out there today, and  
it's unlikely they're going to be universal any time soon.

And even if every IPv6 host were served by a translator, this would be  
problematic because now dual stack hosts will first try to connect to  
the synthetic AAAA address and only then to the real A address.

If people want to make their v4-only services available to IPv6-only  
clients, what they should do is run their own translator locally (or  
arrange to be served by someone else's translator) using global  
unicast IPv6 addresses. Then the entire IPv6 internet will be able to  
connect to those services through that translator and there won't bre  
any problems.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 24 Apr 2009 16:25:09 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Iljitsch van Beijnum
> Sent: Friday, April 24, 2009 2:36 PM
> To: Rémi Després
> Cc: Behave WG
> Subject: Re: [BEHAVE] Questionon embedded address format in 
> draft-baker-behave-v4v6-framework-02
> 
> unicast IPv6 addresses. Then the entire IPv6 internet will be 
> able to connect to those services through that translator and 
> there won't bre any problems.

That falls into the "well-known prefix causes harm" category.

I recall that one of the presentations at the Google IPv6 
conference showed there were a lot of Teredo and 6to4
prefixes advertised in DNS.  If IANA assigns a well known 
prefix for 6/4 translation, we should expect some people
will stick that prefix into their DNS records.  Perhaps
out of incompetence, perhaps while debugging or learning, 
or perhaps because 'it works fine for my site that way'.

-d

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Apr 2009 20:56:43 -0400

> or perhaps because 'it works fine for my site that way'.

I am becoming more and more convinced that a WKP for v4/v6 translation
is a Bad Idea.  That is, it is certain to cause harm, and it's hard to
see how it will actually be of any significant benefit.

Keith

---

From: Xing Li <[email-masked]>
Date: Sun, 26 Apr 2009 21:24:29 +0800

We have an interesting and somehow related observation.

If you try to resolve www.xys.org. You got

% host www.xys.org
www.xys.org has address 69.93.206.250
www.xys.org has IPv6 address ::ffff:69.93.206.250

Can you reach ::ffff:69.93.206.250 via IPv6 Internet?

Our conclusions are:

(1) ::ffff:69.93.206.250 cannot be forwarded on the wire and cannot be 
globally routed.
(2) Configuring an AAAA RR in the source without universally accessible 
IPv6 address is considered HARMFUL.

xing

marcelo bagnulo braun 写道:
> It would be possible to use the IPv4 compatible prefix, but, the 
> problem if we use that is that with current rfc3484 default policy 
> table, the translated connectivity is preferred over the native v4 
> connecitivty, which is an issue
>
>> (This is of course NOT to say that a /96 WKP should be the ONLY way 
>> to map an IPv4 address in an IPv6 address. Many other can exist, in

---

From: Rémi Després <[email-masked]>
Date: Mon, 27 Apr 2009 19:15:38 +0200

> see how it will actually be of any significant benefit.

Very interesting debate.

(A) Here is where, in my understanding, a WKP brings a significant benefit:
If DNS servers of IPv4-ony hosts contain the IPv6 addresses at which 
IPv6-only hosts can reach them, these hosts can be reached by IPv6-only 
hosts without sacrificing DNSsec (while RR translations in DNS64s 
prohibits the use of DNSsec).

(B) Now, here is how to avoid, in my understanding, any short term harm:

1. If the WKP is ::FFFF/96 (that of IPv4 mapped addresses), it is 
already harmful neither to _IPv4-only hosts_ (that don't see AAAAs) nor 
to _IPv4-enabled dual-stack hosts_ (according to RFC 2553 they send in 
IPv4 packets that have mapped address destinations).

The relevant quote from RFC 2553 sec3.7 is:
"Applications may use PF_INET6 sockets to open TCP connections to IPv4
nodes, or send UDP packets to IPv4 nodes, by simply encoding the 
destination's IPv4 address as an IPv4-mapped IPv6 address, and
passing that address, within a sockaddr_in6 structure, in the
connect() or sendto() call."

2. If an ISPs wants to offer IPv6-only addresses to its hosts (that have 
either IPv6-only stacks or dual stacks with IPv4 not enabled ), it is 
sufficient, to avoid suffering any harm, that its DNS64s _translate IPv4 
mapped address prefixes they receive into their ISP specific NAT64 
prefixes_.

With DNS64s doing as proposed in 2., DNSsec compatibility is still 
broken, but not more than without a WKP.

DNSsec deployment being likely to take enough time to prepare a more 
complete solution, as described below.

(C) Finally, here is how to eventually restore DNSsec compatibility.

- Before DNSsec with NAT64s becomes important, make sure that:
  o TCP/IP dual stacks don't discard packets whose destination is the 
mapped address when IPv4 is not enabled, patching them where necessary. 
  (some stacks discarding these packets have been seen to exist).
  o firewalls that discard these packets by default can be configured 
not to do it.
- Then IPv6-only ISPs can:
  o ensure that routes to their NAT64s exist for the mapped address prefix
  o disable the translation of mapped addresses prefixes into 
ISP-specific prefixes.

The end result is that IPv4-only servers, that have advertised their 
mapped address in their DNSsec capable DNS servers (possibly a long time 
ago) become accessible by IPv6-only hosts _that rely on DNSsec_.

Isn't this an interesting promise?

Regards,
RD

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 27 Apr 2009 10:52:33 -0700

> From: Rémi Després [mailto:[email-masked]] 
> Sent: Monday, April 27, 2009 10:16 AM
> To: Keith Moore; Dan Wing; Marcello Bagnulo Braun; Fred Baker
> Cc: 'Iljitsch van Beijnum'; 'Behave WG'; Xing Li
> Subject: Re: [BEHAVE] Question on embedded address format in 

What of
http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02, 
or was it found that we could resolve that harm?  (I noticed
draft-itojun-v6ops-v4mapped-harmful-02 appears to have not been
published as an RFC.)

-d

---

From: Rémi Després <[email-masked]>
Date: Tue, 28 Apr 2009 08:35:04 +0200

Dan,

At the end of a discussion in 2002 on Itojun's draft, Erik Nordmark 
wrote in www.ops.ietf.org/lists/v6ops/v6ops.2002/msg00263:
"An implementation needs to be configured to either be IPv6-only or
dual stack.
In the dual stack case the mapped addresses at the API correspond
to IPv4 packets on the wire.
In the IPv6-only case the mapped addresses at the API correspond
to IPv6 packets on the wire next to the node, and on the other side of
the translator they correspond to IPv4 packets."

I agree with this.

Note that this statement received no objection in 2002, and that 
Itojun's didn't issue a -01 version of his draft.

Regards,

RD

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 28 Apr 2009 10:55:36 -0700

> Sent: Monday, April 27, 2009 11:35 PM
> To: Dan Wing
> Cc: 'Iljitsch van Beijnum'; 'Behave WG'; 'Xing Li'; 'Keith 
> Moore'; 'Marcello Bagnulo Braun'; 'Fred Baker'

More recently, when the question of v4-mapped addresses came up 
Iljitsch ran some tests which Marcelo reported on here:

http://www.ietf.org/mail-archive/web/int-area/current/msg01476.html

The thread continued for quite awhile, and concluded with additional
tests:

http://www.ietf.org/mail-archive/web/int-area/current/msg01515.html
http://www.ietf.org/mail-archive/web/int-area/current/msg01516.html

in that last message (msg01516.html), Iljitsch wrote:

    ...
    >
    >  Conclusions: using the v4-mapped prefix requires changes
    >  for at least some OSes, and probably all or most. Using
    >  the v4-compatible prefix has the advantage that RFC 3484
    >  compatible systems prefer real/normal IPv6 addresses, but
    >  then this would be true for any prefix that is "far" from
    >  the currently used global unicast space (2000::/3), i.e.,
    >  in ::/3 or 4000:/2.
    >
    >  Based on this, I'd say that it doesn't make much sense to
    >  use either of these prefixes for NAT64, but either to use
    >  addresses out of service provider ranges, which has the
    >  downside that configuration is necessary, or define a new
    >  well-known, non-globally-routable prefix for this purpose
    >  which should work without configuration or host changes
    >  (and be less preferred than real AAAA records on RFC 3484
    >  compatible systems, which is most of them apart from
    >  MacOS) and additional benefits can be gained by changes in
    >  the host OS and/or applications.
    >
    ...

Based on that previous discussion (which I admit not everyone
may have seen, as we had a lot of discussion on various mailing
lists in the past):

I believe you saying that such changes to host OSs should be
re-considered to be acceptable/necessary for those 6/4 translation
scenarios where a well-known prefix can be used (i.e., scenario
1: IPv6 network to IPv4 Internet scenario, and scenario 5: IPv6 
network to IPv6 network), so that we can re-use the well-known 
prefix of ::ffff/96 for 6/4 translation.

-d

---

From: Rémi Després <[email-masked]>
Date: Wed, 29 Apr 2009 09:46:24 +0200

> http://www.ietf.org/mail-archive/web/int-area/current/msg01516.html

Thanks for the reference.
Further comment below.

>> Conclusions: using the v4-mapped prefix requires changes for at 
>> least some OSes, and probably all or most. Using the v4-compatible
>>  prefix has the advantage that RFC 3484 compatible systems prefer 
>> real/normal IPv6 addresses, but then this would be true for any 
>> prefix that is "far" from the currently used global unicast space 
>> (2000::/3), i.e., in ::/3 or 4000:/2.

If these OSes send mapped addresses on the wire when their dual stack
has IPv4 enabled, they don't comply with RFC 2553 sec 3.7:
  "Applications may use PF_INET6 sockets to open TCP connections to IPv4
nodes, or send UDP packets to IPv4 nodes, by simply encoding the
destination's IPv4 address as an IPv4-mapped IPv6 address, and
passing that address, within a sockaddr_in6 structure, in the
connect() or sendto() call."

IMHO, they have to be fixed because, by not complying, they prevent
NAT64s and DNSsec can be reconciled as described in
www.ietf.org/mail-archive/web/behave/current/msg05890.

>> Based on this, I'd say that it doesn't make much sense to use 
>> either of these prefixes for NAT64, but either to use addresses out
>>  of service provider ranges, which has the downside that 
>> configuration is necessary, or define a new well-known, 
>> non-globally-routable prefix for this purpose which should work 
>> without configuration or host changes (and be less preferred than 
>> real AAAA records on RFC 3484 compatible systems, which is most of
>>  them apart from MacOS) and additional benefits can be gained by 
>> changes in the host OS and/or applications.

I agree that, before all main OSes are aligned with the above paragraph 
of RFC 2553, it would be premature to advertise mapped AAAAs in DNS 
servers of IPv4-only servers.

But, fortunately, the need for such advertisements comes only when, 
DNSsec being largely deployed, it becomes useful to reconcile NAT64s 
with it. This is not very soon.

The important point though, is IMHO that, in addition to alignment of 
OSes with RFC 2553, DNS64s SHOULD in the short term replace mapped 
addresses by addresses in the provider range, so that:
- they work well in the short term
- they are ready for mapped AAAAs starting to be deployed (by mistake in 
the short term, on purpose when DNSsec is deployed).

These DNS64s should also be ready to disable this replacement when 
DNSsec compatibility becomes desirable.

> Based on that previous discussion (which I admit not everyone may 
> have seen, as we had a lot of discussion on various mailing lists in
>  the past):
> 
> scenarios where a well-known prefix can be used (i.e., scenario 1: 
> IPv6 network to IPv4 Internet scenario, and scenario 5: IPv6 network
>  to IPv6 network), so that we can re-use the well-known prefix of 
> ::ffff/96 for 6/4 translation.

Yes, to permit DNSsec in the IPv6 to IPv4 scenario without disturbing 
OSes that already comply with RFC2553.
(I didn't get the point about IPv6 to IPv6, but the first one stands for 
itself.)

Regards,

RD

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Apr 2009 20:34:21 +0200

> has IPv4 enabled, they don't comply with RFC 2553 sec 3.7:

They don't, they send IPv4 packets, if anything.

> The important point though, is IMHO that, in addition to alignment  
> of OSes with RFC 2553, DNS64s SHOULD in the short term replace  
> mapped addresses by addresses in the provider range

So what you want is that:

1. ::ffff:0:0/96 becomes the NAT64 WKP
2. People running IPv4-only hosts put ::ffff:a.b.c.d AAAA records in  
the DNS
3. People running IPv6-only deploy NAT64s and DNS64s
4. DNS64s translate these AAAA records into a local (provider address  
space) NAT64 AAAA record

But what about people who run dual stack, and thus have no use for  
NAT64 and thus not for a DNS64? They would see the ::ffff:0:0/96  
addresses, which may get them to send normal IPv4 packets but there's  
also a good change that it won't. For instance, the "mapped on the  
wire harmful" meme has been percolating for half a decade and I'm  
willing to bet that at least the NetBSD people filter this out in some  
way.

Also, this is completely unnecessary. The DNS64 can create the fake  
AAAA records from the A records just as easily as from mapped AAAA  

> DNSsec compatibility becomes desirable.

A much simpler way to be compatible with DNSSEC is to simply update  
the DNSSEC validators. Since the DNS64 functionality is new, having an  
integrated DNS64/DNSSEC validator is not a deployment issue. DNSSEC  
validation on the hosts is virtually non-existant, so requiring an  
update to those is not the worst thing in the world and certainly  
easier than upgrading all IPv6 stacks to change their mapped address  
behavior.

Note by the way that the idea of mapping the ::ffff:0:0/96 prefix to  
the NAT64 prefix has some merit, I've suggested things along these  
lines a while ago. If a host doesn't have IPv4 connectivity it could  
perform this mapping, which has the advantage that real A records can  
be used and that the host thinks it's doing IPv4, not IPv6, so it can  
do stuff like enabling IPv4 NAT traversal. But this should be done in  
the host, which knows if there is IPv4 connectivity or not.

On the other hand, may as well use the softwire stuff for this...

---

From: Rémi Després <[email-masked]>
Date: Thu, 30 Apr 2009 09:19:32 +0200

Iljitsch van Beijnum  -  le (m/j/a) 4/29/09 8:34 PM:
>> If these OSes send mapped addresses on the wire when their dual
>> stack has IPv4 enabled, they don't comply with RFC 2553 sec 3.7:
> 

Good remark.
A better statement to support the proposal could have been:
"If they have IPv4 enabled, dual stack OSes that comply with RFC 2553 
sec 3.7 send IPv4 packets when  mapped-address destinations are 
presented to their IPv6 socket interfaces".

> 1. ::ffff:0:0/96 becomes the NAT64 WKP 2. People running IPv4-only
> hosts put ::ffff:a.b.c.d AAAA records in the DNS 3. People running
> IPv6-only deploy NAT64s and DNS64s 4. DNS64s translate these AAAA
> records into a local (provider address space) NAT64 AAAA record

Yes, this is what I propose, with a few more details on when to do what, 
in a previous answer to Keith Moore (ref. 
www.ietf.org/mail-archive/web/behave/current/msg05890).

> also a good change that it won't.

- If they have IPv4 enabled they don't need NAT64.
- If they only their non-updated OSes are assigned only IPv6 addresses 
without having also NAT64s and DNS64s operational, they have no way to 
reach IPv4-only hosts, independently of which DNS RRs are where.

(If an IPv6-only network has to permit non-updated hosts to reach 
IPv4-only servers, it MUST have NAT64s and DNS64s.)

> For instance, the "mapped on the wire harmful" meme has been
> percolating for half a decade and I'm willing to bet that at least
> the NetBSD people filter this out in some way.

This may be the case, but, if my proposal is accepted, this can be fixed 
before mapped DNS64s need to stop translating mapped AAAAs into ISP 
specific NAT64 prefixes (i.e. before IPv6-only to IPv4 connectivity has 
to be reconciled with DNSsec).

> records,

1. The proposal is not that DNS64s stop making synthetic AAAAs with 
ISP-specific prefixes when they do it with received As, it is that they 
ALSO do it with received AAAAs.

2. In my understanding, if (1) DNS64s stop making synthetic AAAAs, (2)
IPv4-only servers have no AAAAs in their DNS servers, then IPv6-only to 
IPv4-only connectivity is broken.

> the DNSSEC validators. Since the DNS64 functionality is new, having
> an integrated DNS64/DNSSEC validator is not a deployment issue.
> DNSSEC validation on the hosts is virtually non-existant, so
> requiring an update to those is not the worst thing in the world and
> certainly easier than upgrading all IPv6 stacks to change their
> mapped address behavior.

In my understanding, if an intermediate DNS64 makes synthetic AAAAs, it 
necessarily breaks the DNSsec provided guarantee that an RR that is 
received does come from the DNS server of the host it points to.

> lines a while ago.

This IMHO supports that time has come to revisit this subject, to be 
sure very carefully, but without any paralyzing taboo.

> If a host doesn't have IPv4 connectivity it could perform this
> mapping, which has the advantage that real A records can be used and
> that the host thinks it's doing IPv4, not IPv6, so it can do stuff 
> like enabling IPv4 NAT traversal. But this should be done in the
> host, which knows if there is IPv4 connectivity or not.
> 

The SAM approach is proposed separately is IMHO in this direction, but 
this is another objective. The scenario for which specification of 
NAT64s and DNS64s is considered is, in my understanding, that of 
IPv4-only servers being reached by non-updated IPv6-only hosts 
(including by non-updated dual stack hosts having IPv6-only addresses).

Regards,

RD