Subject: Re: [BEHAVE] Comments on draft-bagnulo-behave-nat64-00

From: Jari Arkko <[email-masked]>
Date: Sun, 20 Jul 2008 22:42:43 +0300

Dave's suggested change to the nat64 draft makes a lot of sense to me. 
Indeed, it would be unfortunate if the translation mechanism damaged 
what I consider the main v4-v6 co-existence tool, namely dual stack.

However, I'd be interested in learning more about what Iljitsch 
mentioned about current devices not allowing v4-mapped addresses on the 
wire. As Dave mentioned, RFC 2765 uses them, and a quick test on the 
Linux box that I'm writing this e-mail on shows that I can use these 
addresses on the wire. Can you be more specific about what problems you 
expect, and where, Iljitsch?

Jari

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2008 22:27:01 +0200

On 20 jul 2008, at 21:42, Jari Arkko wrote:

> mentioned about current devices not allowing v4-mapped addresses on  
> the wire. As Dave mentioned, RFC 2765 uses them, and a quick test on  
> the Linux box that I'm writing this e-mail on shows that I can use  
> these addresses on the wire. Can you be more specific about what  
> problems you expect, and where, Iljitsch?

IIRC, Itojun was _extremely_ vocal about not allowing these on the  
wire, and I think he got some traction in this area from at least some  
of the *BSD people.

Also, stacks implement special case logic for these addresses as they  
must result in IPv4 packets when the host is dual stack, I don't know  
if this logic is still applied if the host is running IPv6-only, or  
normal IPv6 packets are generated.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 20 Jul 2008 22:33:45 +0200

> normal IPv6 packets are generated.
see http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Jul 2008 13:10:59 +1200

> see http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02

Exactly. This prefix has implied semantics, and worse, it has
*ambiguous* implied semantics: one version for NAT[-PT|64]
and another for the dual-stack socket API.

For NAT64, I think we're reducing topological flexibility by using this
prefix, as well as ignoring the ambiguity. If an arbitrary prefix is
allowed, the NAT64 doesn't have to be in the same administrative domain
as the host.

I suggest therefore having a default prefix plus the option to discover
or configure an alternative.

    Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 21 Jul 2008 08:40:00 +0200

> allowed, the NAT64 doesn't have to be in the same administrative domain

why would it have to be in the same domain as the host if we use the 
v4-mapped prefix?
> or configure an alternative.
but if we use other prefix than the v4-mapped prefix, it is not in the 
default policy table and then we loose the capability mentioned by Dave 
of automatically preffering native connectivity in dual stack hosts, 
which i find very attractive

OTOH, an additional fear that i have using a single globa prefix for 
respresenting the whole v4 address space is that we may end up needing 
to use more specifics, if we want to reach different parts of the v4 
internet through different routes, hence importing the v4 routing table 
to v6, but i don't know if you think there is any ground for this 
concern...?

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Jul 2008 11:49:06 +1200

Hi Marcelo,

> why would it have to be in the same domain as the host if we use the

Well, it's really a rather strange sort of anycast prefix, and I can't
see ISPs being willing to carry explicit routes for it from other ISPs.
Obviously it's technically possible, but I don't see it as likely
to happen.

> which i find very attractive

Agreed, unless there is a non-default policy in place.

> to v6, but i don't know if you think there is any ground for this

Well, we had exactly that concern when designing 6to4, which is why
nothing more specific than 2002::/16 is supposed to be advertised.
You can always write a MUST NOT and hope people obey it ;-)

But 6to4 breaks when the IPv4 network fragments into IPv4 islands.
I'm not sure that we want NAT64 to break then.

   Brian

---

From: Dave Thaler <[email-masked]>
Date: Mon, 21 Jul 2008 17:55:18 -0700

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Sunday, July 20, 2008 6:11 PM
> To: marcelo bagnulo braun
> Cc: Iljitsch van Beijnum; [email-masked]; Jari Arkko; Dave Thaler
> Subject: Re: [BEHAVE] Comments on draft-bagnulo-behave-nat64-00
>

Itojun's draft only has 2 sections that discuss problems:

1.  Dual meaning of IPv4-mapped address

I disagree.  The meaning is a IPv4 destination being used by an IPv6
application.  The packet could be translated from IPv6 to IPv4 in the
sending host, any router along the path, or inside the receiving host.
The semantics are the same in my view.  There are multiple possible
topologies.

I'd argue that this property is actually desirable in some cases
(and this may be one of those cases).

2.  Threats due to the use of IPv4-mapped address on wire

These threats apply equally to the use of any other prefix, and so
are orthogonal to this discussion.

-Dave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 22 Jul 2008 12:28:25 +0200

Dave Thaler escribió:
>>>>> the wire. As Dave mentioned, RFC 2765 uses them, and a quick test
>>>>>           
>> on
>>     
>>>> wire, and I think he got some traction in this area from at least
>>>>         
>> some
>>     
>>>> of the *BSD people.
>>>>
>>>> Also, stacks implement special case logic for these addresses as
>>>>         
>> they
>>     
>>>> must result in IPv4 packets when the host is dual stack, I don't
>>>>         
>> know
>>     
but the problem is that current implementations seem to hardcode that 
the translation can only happen at the api level in the host.

please see the message we sent to the int area ml (this approach of 
having the same disucssion in two ml can be confusing sometimes...)

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

regards, marcelo

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 23 Jul 2008 12:41:46 +0300

> what I consider the main v4-v6 co-existence tool, namely dual stack.

Yep.

> expect, and where, Iljitsch?

To make sure we are not talking past each other - do you mean ::/96 
or ::ffff:0:0/96 ? In the latter case, I believe the Linux IPv6 stack will 
always (try to) send the packet as an IPv4 packet, rendering the address 
unusable from an API perspective, much like port number zero.

I suppose Yoshifuji-san would be the best person to settle this though.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Jul 2008 15:44:05 +0200

> Obviously it's technically possible, but I don't see it as likely

ah, i understand your point now
i was thinking that it is perfectly possible for an ISP to announce the 
prefix to its customers, and i didn't see any problem with that, even 
though they are different admin domains (do you see a problem with that?)

i do understand that it is unlikely that an isp would announce the v4 
mapped prefix to another isp in a peering relationship (it would be 
possible in a transit relationship i think even between isps)  (it would 
be similar to announce the default prefix between isps)

But, in that perspective, i think this also applies to any prefix we 
use. I mean, what seems strange to me is that an isp announces a prefix 
that sinks packet to all the v4 internet to a peer. Actually using the 
pref64 as part of the ISP prefx would end up with the need to perform 
proper filtering, cause a peer isps could send packets with destiantion 
addres containing pref64, that would result in transti to the v4 
internet, which would violate the peering arrangements. So, in a 
different words, i think the argument you raise is more problematic if 
we use the pref64 local that if we use the v4 mapped prefix
> Agreed, unless there is a non-default policy in place.
but you need to configure that and this is more expensive than using the 
default one

it is possible and doesn't require software update, but it is more expensive

> You can always write a MUST NOT and hope people obey it ;-)
ok

> I'm not sure that we want NAT64 to break then.
i am not sure i understand this point (not sure i understand what do you 
mean for 6to4 and not sure how it would apply to nat64, sorry, could you 
expand?

thanks, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Jul 2008 15:45:17 +0200

> (and this may be one of those cases).
i agree this is a desirable behaviour, only that for practical reasons 
can be cumbersome to deploy

> are orthogonal to this discussion.

i agree this one is bogus.

regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jul 2008 11:23:01 +1200

In line (sorry about the growth in message size...)

> though they are different admin domains (do you see a problem with that?)

No, I think this is OK, but of course that won't help customers of an
ISP that doesn't choose to offer NAT64 service.

> be similar to announce the default prefix between isps)

Exactly (unless there was an explicit agreement that ISP A would provide
NAT64 service for ISP B's customers).

> we use the pref64 local that if we use the v4 mapped prefix

Yes, it would be an "interesting" case if the NAT64's prefix was
included in a shorter prefix that was announced to the DFZ. Good point.

> it is possible and doesn't require software update, but it is more

Definitely. But despite the above issue, it does allow for more
flexibility. It is a MAY of course.
> mean for 6to4 and not sure how it would apply to nat64, sorry, could you

Easiest is to look at http://tools.ietf.org/html/rfc3056#section-5.5
The scenario that fails for 6to4 is the second one, where IPv4
connectivity is assumed to have fragmented in a late stage of transition
to IPv6. I guess this deosn't map directly to NAT64, so this is probably
a false problem, sorry.

(We could consider a scenario where IPv4 has fragmented and we use
double-NAT64 to interconnect IPv4 islands, but that sounds too bizarre.)

    Brian