Subject: [Int-area] practical issues with using v4-mapped addresses for nat64

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

Hi,

(discussing this in int area rather than behave following the guidelines 
of the ADs)

Dave suggested that we could use v4-mapped addresses to represent v4 
addresses in v6 land, when using the nat64.

This has the advantage that dual stack nodes will automatically prefer 
native v6 connectivity cause the rfc3484 default policy table implies that.

(the main argument is that if we use a different prefix, dual stack 
hosts will need to implement some way to determine which is translated 
connectivity vs translated connectivity, so legacy hosts, will not be 
able to distinguish that and may end up using translated connectivity 
and the apps that don't work through nat would fail)

We have been doing some tests about how current OSes work with v4-mapped 
addresses and the results are not very encouraging.

We (well, mostly Iljitsch actually) have made the following simple trial 
scenario.

We have a IPv6 server and we have created the following RR:

All under runningipv6.net:

test1           IN      AAAA    ::ffff:83.149.65.1

test2           IN      AAAA    ::ffff:83.149.65.1
                IN      AAAA    2001:1af8:2:5::2

note that ::ffff:83.149.65.1 is unreachable in IPv6, but 83.149.65.1 is 
reachable in IPv4.

So, when we have a dual stack machine as a source, the following happens 
when we try to go to these FQDNs using Safari on Mac or IE on Vista (we 
captured the packets to determine which IP version was used):

Both Windows vista and MacOS Leopard Dual stack connecting to test1: it 
works so it sends IPv4 packets... this seems reasonable, but i wonder if 
it is always ok.
Both Windows vista and MacOS leopard Dual stack sending to test2: it 
works and it they both send IPv6 packets, (this is what we want!)

When we have a source machine that is v6-only (i.e. the v4 stack is 
disabled), the following happens:
MacOs Leopard v6-only stack sending to test1: doesn't send any packets
Windows vista sending packets to test1: doesn't send any packet

MacOs Leopard v6-only sending packets to test2: stalled and then works 
using v6 packets, so it seemed it has preferred first the mapped address 
and then fall back to the real v6
Windows vista sending packets to test2: it works, so it preferring the 
real v6 address right away

So, the conclusion from this is that we have a problem with v6 only 
hosts, since they seem to assume that v4-mapped are not usable when the 
v4 stack is down, even when they get this address in a dns AAAA RR.
So according to this, using the v4-mapped address would imply that v6 
only nodes would not work and would need updating. If this is the case, 
then i think we are better of with the other failure mode i.e. dual 
stack nodes sometimes preferring translated connectivity i think, cause 
seems a less severe failure and can be avoided by not exposing synthetic 
AAAA RR to dual stack hosts (which can be done by having no DNS64 
functionality in the NDS server that is serving the dual stack hosts)

(the other possibility is that we got our tests wrong :-) We did this in 
a minute, so it may well be wrong.

So this needs host updates in the most popular OSes. Alternatively, we 
could depend on the fact that A records result in v4-mapped addresses in 
the stack anyway and forego the DNS64 step, but in that case changes are 
also necessary because the resolver only provides v4-mapped addresses to 
applications when there is IPv4 reachability.

We have left the RR in the server, in case anyone else want to try them 
and share the results.

We have additional RR so you can have more fun

All under runningipv6.net:

test1           IN      AAAA    ::ffff:83.149.65.1

test2           IN      AAAA    ::ffff:83.149.65.1
                IN      AAAA    2001:1af8:2:5::2

test3           IN      AAAA    ::ffff:83.149.65.1
                IN      A       83.149.65.1

test4           IN      AAAA    ::ffff:83.149.65.1
                IN      AAAA    2001:1af8:2:5::2
                IN      A       83.149.65.1

Regards, Iljitsch and marcelo

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Dave Thaler <[email-masked]>
Date: Tue, 22 Jul 2008 17:25:10 -0700

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]
> Sent: Monday, July 21, 2008 4:01 AM
> To: [email-masked]
> Cc: Dave Thaler; Dan Wing; Jari Arkko; Iljitsch van Beijnum; Philip
> Matthews; Brian E Carpenter; Alberto García
> Subject: practical issues with using v4-mapped addresses for nat64
>
> Hi,
>

Yes, this is excellent news.

> So this needs host updates in the most popular OSes.

I think you need to consider what scenario you're targeting NAT-PT for.
I would argue that a dual-stack OS with IPv4 disabled is not a common
scenario.  Hence while I agree that the OS's tested appear to be
problematic, it's not clear to me that that's a very useful data point.

Remember that the case you're evaluating here is a dual-IP-version
network, not a v6-only network (I believe we already agreed the
question is moot in a v6only network).  If you have a dual-IP-version
network and a host OS that supports both IPv4 and IPv6, why would
anyone disable IPv4 on the host?  That doesn't seem like a very
important case to me.

The real v6-only scenario you want to test is stacks/devices that have
_no_ IPv4 implementation at all, and you want to know whether those
treat v4mapped addresses the same way as any other native IPv6 address
when connected to a dual-IP-version network.

-Dave

> Alternatively, we

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Jul 2008 17:29:06 -0700

On Jul 22, 2008, at 5:25 PM, Dave Thaler wrote:
> If you have a dual-IP-version

Perhaps because you don't have any IPv4 addresses to hand out, and  
don't want to run a multilevel NAT infrastructure?

---

From: Dave Thaler <[email-masked]>
Date: Tue, 22 Jul 2008 17:31:40 -0700

No IPv4 addresses to hand out == IPv6-only network
(for purposes of this discussion anyway)

-Dave

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ted Lemon
> Sent: Tuesday, July 22, 2008 5:29 PM
> To: [email-masked]
> Subject: Re: [Int-area] practical issues with using v4-mapped addresses
> for nat64
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Jul 2008 17:35:20 -0700

> (for purposes of this discussion anyway)

-ish.   You may have IPv4 addresses only for selected hosts.   But  
you're right that I didn't catch that part of what you were  
saying... :'}

---

From: Dave Thaler <[email-masked]>
Date: Tue, 22 Jul 2008 18:01:48 -0700

Yeah.  If you can distinguish 'selected' hosts (e.g., by
vendor class identifier, or whatever else), then you
can give a DNS64 address to the ones that aren't "selected"
and you give normal DNS server addresses to ones that are
"selected" for IPv4 addresses.

-Dave

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Tuesday, July 22, 2008 5:35 PM
> To: Dave Thaler
> Cc: [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Jul 2008 12:01:36 +0200

On 23 jul 2008, at 2:25, Dave Thaler wrote:

>> works so it sends IPv4 packets... this seems reasonable, but i wonder
>> if it is always ok.

> Yes, this is excellent news.

Not really, because it doesn't buy us anything: it just means that on  
dual stack systems, the mapped addresses in AAAA records don't get in  
the way.

What we need is for IPv6-only systems to successfully send and receive  
IPv6 packets with mapped addresses as the source or destination. And  
we haven't seen any type of system do this so far.

> problematic, it's not clear to me that that's a very useful data  

We were able to quickly test with IPv4 disabled, testing with IPv4  
enabled but no IPv4 available would have taken considerably more time.

In theory no IPv4 means no IPv4, regardless of why, but there is the  
possibility that this makes a difference, as I've seen some  
applications on my Mac work over IPv6 with IPv4 enabled but not  
available but fail with IPv4 disabled.

> question is moot in a v6only network).

What question?

NAT-PT/NAT64 inherently address hosts that only have IPv6  
connectivity, probably because there is no IPv4 available even though  
the hosts support it, but possibly because the host doesn't have a v4  
stack.

> anyone disable IPv4 on the host?  That doesn't seem like a very

Right. But for a quick test it's much easier to turn off IPv4 for an  
interface on a host rather than convince the IT department to turn off  
IPv4 on the production network or go into the lab and set up an IPv6- 
only network, so that's what we did.

I gather that in Dublin we'll once again have an IPv6-only network, so  
perhaps we should retest there.

> when connected to a dual-IP-version network.

Do systems like that exist today?

Obviously we're trying to come up with something that will be useful  
on systems that are in wide use within the next few years, which means  
it must work on existing Linux, Windows and MacOS, if not on the  
current versions then on versions that can be pushed out as  
incrimental updates within a couple of years.
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Jul 2008 13:03:12 +0300

Marcelo, Iljitsch, what was the method you used to "disable v4"?

I agree with Dave that an important scenario to consider for this 
particular functionality is a host without any v4 stack; but since there 
aren't many of those its going to be hard to test this. In some sense we 
can rely on future implementors to do the right thing, particularly if 
we publish documents saying what the right thing is.

However, another important scenario that I would like to test is having 
a normal host (say, Vista or Linux) that can support both versions, and 
then running that in a network that has no IPv4. That is, DHCPv4 does 
not respond, routers do not route IPv4 packets, etc. (The host might 
come up with some link local addresses, however.) In that environment, 
what happens? If typical implementations fail in some manner in this 
scenario, it means that the NAT-PT replacement is going to have a hard 
time in any network except those involving purpose built new hosts...

Jari

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Jul 2008 12:54:22 +0200

[why aren't my messages making it to lists? sending again...]

Jari, this should answer your message just now, I suggest we get some  
people together and do some more testing in Dublin.

What question?

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Jul 2008 16:41:42 +0200

> Marcelo, Iljitsch, what was the method you used to "disable v4"?
In both cases, we have unclicked the v4 support

In the macos we have included the v4 on the interface to off

In the windows, we went to the protocols and unclick the tcp/ip v4 item

> particular functionality is a host without any v4 stack; but since 
> there aren't many of those its going to be hard to test this. In some 
> sense we can rely on future implementors to do the right thing, 
> particularly if we publish documents saying what the right thing is.
>
> However, another important scenario that I would like to test is 
> having a normal host (say, Vista or Linux) that can support both 
> versions, and then running that in a network that has no IPv4. That 
> is, DHCPv4 does not respond, routers do not route IPv4 packets, etc. 
> (The host might come up with some link local addresses, however.) In 
> that environment, what happens? If typical implementations fail in 
> some manner in this scenario, it means that the NAT-PT replacement is 
> going to have a hard time in any network except those involving 
> purpose built new hosts...
>
we can do this in the ietf network next week
volunteers? maybe we can get togehter on sunday and try it out and we 
can present the results in the in area
Iljitsch and myself we have macoc, we need volunteers with linux, 
windows, and anyhting else you find interesting

please contact us offline for this

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Jul 2008 16:51:42 +0200

Dave Thaler escribió:
>> if
why not?
I thought this was one of the primary scenarios..
I mean, i though we were targetting for the case when there are no more 
v4 addresses and people deploy v6 networks

I mean, if we have dual stack and we have v4 connectivity, we don't need 
natpt, since we can reach the v4 network using ipv4... i must be missing 
something very obvious here, could you explain?

besides, the problem that we have identified is that when a stack wnats 
to send a packet towards a an addrerss that contains the v4 mapped 
prefix, it will send an IPv4 packet and would never send an IPv6 packet 
with an v4 mapped prefix in the destiantion address and that is 
problematic. this behaviour was evident in the experiemnt, but the real 
underlying problem is that if we use the v4 mapped prefix to represent 
v4 addresses in v6 and for nat64, the problem is tha current stacks will 
never generate a v6 packet with that derstiantin address to be 
translated by the nat64 box.

or am i misunderstanding the problem?

>  Hence while I agree that the OS's tested appear to be
i don't follow

i think that the dual stack network with v4 connectivity will use ipv4 
to reach the v4 internet, right?

> anyone disable IPv4 on the host?  That doesn't seem like a very
cause you don't have a v4 address, so you need to rely on ipv6

> when connected to a dual-IP-version network.
right, but we cnanot test this, right?

Regards, marcelo

---

From: Dave Thaler <[email-masked]>
Date: Wed, 23 Jul 2008 14:05:16 -0700

[...]
> v4 addresses and people deploy v6 networks

People that deploy v6-only networks will just hand out a DNS64 server
address as the IPv6 address all clients should use for their DNS server.
So all I meant is that there's no need to distinguish hosts that are not
IPv4-capable vs hosts that have an IPv4 stack disabled vs hosts that
have both IPv4 and IPv6 enabled (but no IPv4 address).

I think your point is that in an IPv6-only network, native IPv4
obviously won't work, and having v4mapped addresses on the wire won't
work from the current dual-stack OSs tested.  So you either need them
fixed or you need them to use some prefix other than the v4mapped range.

Hence Brian Carpenter's suggestion to default to v4mapped but allow
configuration to support some other prefix, which sounds reasonable.
There's no magic answer that's occurring to me.

However, I would still argue strongly that we should not require changes
to existing dual-stack nodes in order to deploy something that doesn't
break apps.  (Requiring changes in IPv6-only nodes is much less bad,
although still undesirable.)

For informational purposes, it might be interesting to
repeat your experiments using the range ::/96 (the range reserved for
IPv4-compatible addresses, which were deprecated but are still in
the RFC 3484 table as less preferred than native IPv6, just above
the v4mapped range).

I just tried on Vista SP1 and it does send out a packet natively to
a ::/96 address, although I believe Windows XP still supported
v4-compatible tunnels and so won't (but XP doesn't claim to work
on IPv6-only networks).

-Dave

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jul 2008 14:43:25 -0700

> v4-compatible tunnels and so won't (but XP doesn't claim to work

Just to be clear, do you mean that if an IPv6 app opens an IPv6 socket  
and connects to a ::/96 address, the Vista network stack forms an IPv6  
frame and sends it to that address just as it would to any ordinary  
IPv6 address?

---

From: Dave Thaler <[email-masked]>
Date: Wed, 23 Jul 2008 14:51:07 -0700

Correct.

Just like deprecating site locals resulted in people treating them
same as globals (no special case), deprecating v4-compatibles
resulted in treating them same as globals (no code checks for
this range).  I don't know how non-Windows OSs deal with this,
hence my suggestion that Marcelo/Iljitsch try this on the
other OS's they're checking for comparison.

-Dave

> Sent: Wednesday, July 23, 2008 2:43 PM
> To: Dave Thaler
> Cc: [email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 24 Jul 2008 08:27:46 +0300 (EEST)

On Wed, 23 Jul 2008, Iljitsch van Beijnum wrote:
> Not really, because it doesn't buy us anything: it just means that on dual 
> stack systems, the mapped addresses in AAAA records don't get in the way.
>
> What we need is for IPv6-only systems to successfully send and receive IPv6 
> packets with mapped addresses as the source or destination. And we haven't 
> seen any type of system do this so far.

I'm not sure that "we" (if it implies the IETF and network community 
in general) need to be able to send and receive v6 packets with mapped 
addresses as the source or destination.

Why is using the mapped addresses on the wire such a holy grail of 
v6-only operation?

As a destination address, it might result in IPv6 DFZ being polluted 
with the corresponding v4 routes except if you only use it in very 
restricted environments (e.g. default route only).

As a source address, if the node(s) on link are also provided with 
real IPv6 addresses, this would be indistinguishable from source 
address spoofing.

I'd like folks to just forget about the mapped addresses on the wire 
and find other kind of solutions for this problem.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jul 2008 22:51:42 -0700

> restricted environments (e.g. default route only).

I really don't think that this is a serious problem in practice.   As  
long as we need to exchange packets between the V4 and V6 networks, we  
will have gateways at strategic points that do this.   I was just  
observing the other day that I simply never use a routing table with  
anything other than a default route in practice anymore.

I'm going to make an extremely naive observation, because I haven't  
been here through all the big battles over IPv6 addressing.  When I  
read Alain's draft I concluded quickly that it didn't meet my needs -  
it's more something that he needs.   But I do see a need for 6-to-4  
NATting nevertheless, and I am naive as to the reasons why people  
don't like 6-to-4 NATting (other than the ones that apply to NATting  
in general).

The observation is that an IPv6-native node could, when an application  
opens a socket and connects to an IPv4 address (or sends a datagram)  
form an IPv6 packet with an IPv4-mapped destination address.   This  
would require no change to the application - in many cases it would  
Just Work, and in those cases where it wouldn't, the application  
really can't be done without being IPv6-aware anyway.

This IPv6 packet would be routed by the native IPv6 routing  
infrastructure to some kind of 6-to-4 NAT, which would repackage the  
packet as an IPv4 packet and send it on its way, spoofing the source  
address as NATs unfortunately must do.

I wouldn't say this is the holy grail or anything, but right now I  
simply can't use IPv6-only nodes.   It's not practical.   So even an  
ugly bandaid that makes it possible for me to deploy an IPv6-only node  
that has all the functionality of a NATted IPv4 node, plus end-to-end  
IPv6, is a huge win over what I would be doing instead - an IPv4 NAT  
with net 10 or 192.168 IP addresses.

So while I would describe this as an ugly bandaid, it's a lot less  
ugly than what I'm using now.   But as I say, I'm probably being naive.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Jul 2008 10:06:27 +0200

Dave Thaler escribió:
> [...]
>   
>>> I think you need to consider what scenario you're targeting NAT-PT
>>>       
>> for.
>>     
agree
> fixed or you need them to use some prefix other than the v4mapped range.
exactly
> There's no magic answer that's occurring to me.
this other prefix would be also a global prefix or is a local prefix 
assigned by the local network for this (i.e. what we called the Pref64 
in the nat64 draft)

> although still undesirable.)
mmm, so you think we should include that in the requirements draft?

(btw i agree with the requirement in general)

> the RFC 3484 table as less preferred than native IPv6, just above
good point

actually this is already contained in the rfc3484 default policy table, 
so it would provide the benefits of the v4mapped, maybe withotu the problems

> v4-compatible tunnels and so won't (but XP doesn't claim to work
good!
we are organizing a trial of this in the v6 only network at the ietf on 
sunday, so we cna report back on the meeting
(again, if people are interested to join, let me know)

So, we have then 4 options so far:

- v4mapped prefix
- v4compatible prefix
- another global prefix assigned by iana for this
- use of local prefixes in each site

For me, if the compatible prefix doesn't has the problems of the v4 
mapped prefix, would be the best option at this point.
It is not so obvious to me the choice between the last two, though

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Jul 2008 10:11:47 +0200

Pekka Savola escribió:
>> What we need is for IPv6-only systems to successfully send and 
>> receive IPv6 packets with mapped addresses as the source or 
>> destination. And we haven't seen any type of system do this so far.
>
what about v4 compatible address? do you see problems in there?
Regards, marcelo
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Jul 2008 10:13:15 +0200

> address as the IPv6 address all clients should use for their DNS  

(Don't forget that until the EDNS0 SAS option is supported, you really  
don't want to give hosts with dual stack reachability synthetic AAAA  
records.)

> configuration to support some other prefix, which sounds reasonable.

No, this is a bad solution, because it requires that we address the  
limitations of both options, and ISPs may opt for one while end-user  
equipment only supports the other.

We need to pick one. If people then choose to implement administrative  
overrides, that's their choice, but that means that the burden to make  
it work is on those implementers/operators.

> although still undesirable.)

Well, for things to work well, we pretty much need updates: the EDNS0  
option if we go with arbitrary translator prefixes, allowing v4mapped  
addresses on the wire if we go with v4mapped.

Fortunately, all systems that we can assume to run in IPv6-only  
environments in the future can download patches over the internet, so  
this isn't a show stopper.

At the same time, it is of course very helpful to make sure that  
unupdated systems can work reasonably well. But I don't think we  
should optimize for this at the expense of having a solution that  
works well on updated hosts.

> repeat your experiments using the range ::/96

Sure, as long as we're testing anyway. Not sure what the advantages of  
using this range would be, though.
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Jul 2008 10:33:16 +0200

> in general) need to be able to send and receive v6 packets with  
> mapped addresses as the source or destination.

The premise being that we'd use the v4mapped prefix for NAT64.

> Why is using the mapped addresses on the wire such a holy grail of  

See my list of advantages the other day.

The most compelling is that applications that think they're using IPv4  
will work. With existing NAT-PT or the NAT64 draft as it is now this  
isn't the case.

I.e., when I was at the LACNIC meeting IPv4 was turned off, but unlike  
at the last IETF meeting, there was a NAT-PT translator present. So I  
could browse the web, connect to Jabber, send/receive email etc even  
though the servers didn't have IPv6 addresses.

However, a SIP client, Skype and BitTorrent didn't work: they  
explicitly use IPv4 addresses, which weren't reachable. Obviously  
those clients can be upgraded, but it would be extremely useful if  
existing IPv4 applications could work through a NAT64 translator.

On the other hand, this can also be accomplished with an arbitrary  
prefix if the host knows the prefix and intercepts API calls that  
would normally generate IPv4 packets but turn those into IPv6 packets  
towards the translator if there is no IPv4 connectivity.

> restricted environments (e.g. default route only).

Yes, and if the sky fell we'd all be covered in blue.

As far as I know, this hasn't happened with the 6to4 prefix so I see  
no reason to reject using a well known prefix to avoid this risk.

> real IPv6 addresses, this would be indistinguishable from source  

Only translators would transmit packets with v4mapped source  
addresses, so this isn't much of an issue.

> and find other kind of solutions for this problem.

Please provide better reasons.
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Shin Miyakawa <[email-masked]>
Date: Thu, 24 Jul 2008 18:13:09 +0900 (JST)

From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: [Int-area] practical issues with using v4-mapped addresses for nat64
Date: Thu, 24 Jul 2008 10:33:16 +0200
> though the servers didn't have IPv6 addresses.

Google cache (for example, http://www.google.com/search?q=IETF and
please go to "chache" section of it) is using IPv4 address in the URL like 

http://72.14.235.104/search?q=cache:vtraHFRvKEsJ:www.ietf.org/rfc.html+IETF&hl=ja&ct=clnk&cd=2 

Which means you could not browse those types of URLs through NAT-PT translator.

So, as a commercial ISP, we do not think NAT-PT can be acceptable by customers.
This is the reason why we have to do dual stack (by 4-4 NAT, dual stack lite,
snat or whatever).

> explicitly use IPv4 addresses, which weren't reachable. 

True. But again, please note that not only those applications 
but also many web pages like google cache are not compatible with NAT-PT.

> Obviously those clients can be upgraded, but it would be extremely useful if  

True. But it is very hard or impossible I think.

It seems to me that just making those applications IPv6 compatible is 
the easiest and the least expensive way....

Best wishes,

Shin Miyakawa

---

From: Jari Arkko <[email-masked]>
Date: Thu, 24 Jul 2008 12:23:10 +0300

Marcelo, Dave,

> I mean, i though we were targetting for the case when there are no 
> more v4 addresses and people deploy v6 networks
>
> I mean, if we have dual stack and we have v4 connectivity, we don't 
> need natpt, since we can reach the v4 network using ipv4... i must be 
> missing something very obvious here, could you explain?
I think it is a requirement that if you have a v6-only network, you must 
be able to take your (current) dual-stack host into this network and not 
have breakage.

Jari

---

From: Julien Laganier <[email-masked]>
Date: Thu, 24 Jul 2008 16:34:59 +0200

> There's no magic answer that's occurring to me.

FWIW:

faithd, an IPv6-to-IPv4 TCP relay for *BSD, and totd, a DNS proxy and 
translator for IPv6 and IPv4, works by embedding IPv4 addresses into 
IPv6 ones thanks to use of a designated, locally assigned IPv6 prefix:

<http://www.daemon-systems.org/man/faithd.8.html>
<http://www.aioe.org/cgi-bin/man2web?program=totd&section=8>

I'd used that setup in 2003 on an IPv4-free FreeBSD laptop (i.e. no IPv4 
address configured) for daily use (e.g. mail, www, etc.) and it worked 
well.

In case somone has no globally routable IPv6 prefix assigned, it is 
possible to use a ULA prefix. It could also has the "advantage" to 
limit the risk of packets containing these IPv4 addresses embedded in 
IPv6 addresses as destination leaking in the outside Internet.

--julien

---

From: Dave Thaler <[email-masked]>
Date: Thu, 24 Jul 2008 13:45:45 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Thursday, July 24, 2008 1:13 AM
> To: Dave Thaler
> Cc: marcelo bagnulo braun; [email-masked]; Dan Wing; Jari Arkko;
> Philip Matthews; Brian E Carpenter; Alberto García
> Subject: Re: practical issues with using v4-mapped addresses for nat64
>

Sounds like the case you're talking about is a multi-homed client.
Since above we're talking about v6-only networks, but hosts with
dual stack reachability.

> it work is on those implementers/operators.

I think it also depends on the scenario.  If you're putting NAT64
close to the client (i.e. matching the default route is ok) then
you can use a well-known range.

If you're putting NAT64 across the internet from the hosts that
will use IPv6 (e.g. closer to IPv4-only servers, at the edge of
a v4-only network), then you need a routable prefix.

That's why I want pictures in the draft to see which scenarios you're
targeting.

> addresses on the wire if we go with v4mapped.

I'm not yet convinced that we need updates to existing dual stack nodes.

> works well on updated hosts.

I work for a company that does patches over the Internet.  The bar
for pushing patches automatically to existing hosts is very high
(basically security fixes only).  And if it's not automatic, just
available, then you have to assume that most hosts won't have it.
Hence we do need to optimize for unmodified hosts in my view,
at least for the short term.

> using this range would be, though.

Marcelo already answered this... existing hosts sort them after
native IPv6 addresses.

-Dave

---

From: Pekka Savola <[email-masked]>
Date: Fri, 25 Jul 2008 08:23:13 +0300 (EEST)

On Thu, 24 Jul 2008, Iljitsch van Beijnum wrote:
> last IETF meeting, there was a NAT-PT translator present. So I could browse 
> the web, connect to Jabber, send/receive email etc even though the servers 
> didn't have IPv6 addresses.
...
> On the other hand, this can also be accomplished with an arbitrary prefix if 
> the host knows the prefix and intercepts API calls that would normally 
> generate IPv4 packets but turn those into IPv6 packets towards the translator 
> if there is no IPv4 connectivity.

Exactly! As you demonstrated, host stacks needs to be modified no 
matter what.

If you choose a prefix that is supposed to be "well known" (used by 
all implementations), you could overload the existing use of mapped 
addresses, or choose something else altogether.  Given that you can't 
depend on the existing behaviour of mapped addresses anyway, if you go 
this "fixed address block" route, the least astonishing failure modes 
could be achieved with a new special prefix.

Now, as you say, the node could also signal the prefix somehow.  As 
Julien Laganier wrote, these kind of deployments (with faithd, totd, 
etc.) have already been used for a long time.  As the prefix is 
dependant on the network, there are no source spoofing, routing table 
pollution, etc. problems.

If you don't signal anything, the result is that you spew out packets 
with the mapped addresses with the assumption that there is going to 
be a translator somewhere along the path that's going to do something 
to them.  Otherwise they end up transiting enterprise and backbone 
networks and potentially arriving at the destination which does 
something unexpected with that, e.g. discard them or end up waiting in 
SYN-RECEIVED state.  IMO, it seems better to not send packets out 
unless you know they are going to be useful for someone.

What seems to be missing is a good way to signal the prefix and some 
modifications to API calls.  As demonstrated, stack modifications are 
already needed (at least in API handling), so why not do it all the 
way?

>> As a source address, if the node(s) on link are also provided with real 
>> IPv6 addresses, this would be indistinguishable from source address 
>> spoofing.
>
> Only translators would transmit packets with v4mapped source addresses, so 
> this isn't much of an issue.

(I thought the mapped addresses would have been used between a host 
and a translator -- or, if there doesn't happen to be translator, the 
packets would end up in the destination network. But maybe not..)

So we're required to trust that anyone running a translator in the 
Internet is honest netizen?

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 25 Jul 2008 09:31:27 +0200

Hi Pekka,

Pekka Savola escribió:
>> last IETF meeting, there was a NAT-PT translator present. So I could 
>> browse the web, connect to Jabber, send/receive email etc even though 
>> the servers didn't have IPv6 addresses.
> ...
well, not really
If you use a local prefix as currently done, you don't need to modify 
the hosts, right?

> could be achieved with a new special prefix.
the problem that Dave has pointed out, is that if you use a local 
prefix, the dual stack hosts can't tell if there is native connectivity 
or translated connectivity and that if they select translated 
connectivity the apps that don't work through nats would break.

the goal is to solve that

using mapped prefixes was one option, but i understand that it doesn't 
work for legacy hosts, so no arguing with that

the  next question is what about v4 compatible prefix? could we use that 
one?

the benefit of this one is that it is also in the defaul policy table in 
rfc3484 and it then allows dula stack hosts to preffer native 
connectivity than translated connectivity,

> pollution, etc. problems.
I would like to understand which are all these problems in more detail
could you expand in source spoofing and in route pollution?

> to them.
not really you would only generate packets towards a v4mapped (or any 
prefix selected for nat64) if you have receive a synthetic AAAA RR for 
that destiantion, which only happens if you have a dns64 which should 
only happen if you have a nat64 in the path

> Otherwise they end up transiting enterprise and backbone networks and 
> potentially arriving at the destination which does something 
> unexpected with that, e.g. discard them or end up waiting in 
> modifications to API calls.

i understand the need for signalling the prefix, what do you need an api 
call for? how do you deal with legacy dual stack hosts to not use 
translated connecitivity when native is available?

regards, marcelo
>   As demonstrated, stack modifications are already needed (at least in 
> API handling), so why not do it all the way?
>

---

From: Pekka Savola <[email-masked]>
Date: Fri, 25 Jul 2008 12:23:00 +0300 (EEST)

Maybe I shouldn't have stuck my finger on this because it seems I 
don't have a clear idea what are the scenarios being discussed.  I 
hope this gets clarified in some document at some point..

On Fri, 25 Jul 2008, marcelo bagnulo braun wrote:
>> Exactly! As you demonstrated, host stacks needs to be modified no matter 
>> what.
>> 
> well, not really
> If you use a local prefix as currently done, you don't need to modify the 
> hosts, right?

Right (at least modify in this respect), my above comment was written 
in the context using the mapped addresses.

>> If you choose a prefix that is supposed to be "well known" (used by all 
>> implementations), you could overload the existing use of mapped addresses, 
>> or choose something else altogether.  Given that you can't depend on the 
>> existing behaviour of mapped addresses anyway, if you go this "fixed 
>> address block" route, the least astonishing failure modes could be achieved 
>> with a new special prefix.
>
> the problem that Dave has pointed out, is that if you use a local prefix, the 
> dual stack hosts can't tell if there is native connectivity or translated 
> connectivity and that if they select translated connectivity the apps that 
> don't work through nats would break.

Are we discussing a scenario where a v6-only host is in a network 
where the link it attaches to has no v4 (but further upstream there 
could be but necessarily isn't)?  If so (there is no fallback possible 
to v4) there is no point in giving the host another prefix unless 
you're at the same time able to signal how it's special and that it's 
in fact being used in the network for something.  This seems to call 
for something like a DHCPv6 option.  The same DHCPv6 message exchange 
could deploy address selection policies to the host.

Or are we talking about "local prefix" in the sense, "DNS-ALG will use 
the local prefix to change responses, but the prefix isn't used to 
assign addresses on a host" ?

...
> the  next question is what about v4 compatible prefix? could we use that one?
>
> the benefit of this one is that it is also in the default policy table in 
> rfc3484 and it then allows dula stack hosts to preffer native connectivity 
> than translated connectivity,

Compatible is slightly better because it doesn't overload existing 
non-obsoleted addressing mechanism.  But still -- what would be the 
benefit of a host sending packets out with v4 compatible destination 
addresses if it doesn't know that some translator is going to do 
something with them?  Are you assuming either that translators would 
be prevalent enough that attempting such communication would be 
feasible?  Or that it doesn't cause that much harm?  Or something 
else?  My point here is that there already should be a requirement to 
signal the presence of a translator in the network, and if there is, 
we could piggyback the rest of the configuration with that.

Maybe an important distinction is whether your peers (or those wishing 
to initiate sessions to you) also need to understand the prefix, and 
if so, why.  (Why isn't obvious to me at the moment because usually 
they don't have alternatives to choose from.) On the other hand, it's 
easier if only the host and/or the local site needs to understand the 
prefix.

> could you expand in source spoofing and in route pollution?

How does the first hop router verify that a packet with a special 
source address was correctly sent (to the same level of correctness as 
available with unicast RPF check on the router or proposed SAVI WG 
mechanisms)?

If such packets are forwarded beyond the first hop router (e.g., from 
an enterprise network to ISP), how does the ISP verify that the 
enterprise is not sending junk with addresses it doesn't have (e.g. 
flooding attacks)?

Or are the special source addresses routable back to the networks 
originating them?  (If they aren't how could such one-way 
communication be useful?)  If they are routable, wouldn't this more or 
less require that v6 BGP and routing would also need to route these 
special prefixes for all the v4 prefixes currently or previously 
used?

The result could be that the core routers would need to carry IPv4 
routing table, IPv6 native routing table and IPv6 embedded routing 
table (a subset of v4 routing table).

> i understand the need for signalling the prefix, what do you need an api call 
> for? how do you deal with legacy dual stack hosts to not use translated 
> connecitivity when native is available?

Not sure about the API.  I guess it depends on how you deploy the 
name->address mapping.  I guess the host could also query both and 
synthetize a response.  This might imply API modifications.  You could 
possibly do without them with a different placement of mapping 
function.  Not sure whether/how the application would need to be able 
to signal its interest for v4/v6-pure/v6-translated connectivity -- 
maybe the stack can figure it out on its own.

Wrt legacy dual stack, it doesn't feel like a strong requirement to be 
able to avoid modifications to v6 code.  Deploying local v6 policies 
is already existing code though (not sure of its practicability).

If you don't deploy additional addresses to hosts, the only point of 
consideration is when a mapping function like DNS would return 
multiple entries -- for a v6-only host, a v6-only response requires no 
change.  v4-only response requires translation, but the host has no 
alternative so that's trivial.  A v6+v4 response could be either a) 
left as is, b) augmented to v6+v4trans+v4, c) changed to v6+v4trans, 
or d) v4 removed, ie. changed to just v6.  In this case, if v6 
connectivity would work OK to destinations advertising v6 connectivity 
(I suspect it should if you're willing to deploy v6-only hosts and 
networks!), a) or d) could both be viable options and there is no 
selection problem.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Jul 2008 10:16:33 +1200

> you can use a well-known range.

I agree with Iljitsch to the extent that this should be a
MUST implement.

> a v4-only network), then you need a routable prefix.

Indeed, but this is clearly more complex, will need configuration
or discovery, and I think should probably be MAY implement.

> I'm not yet convinced that we need updates to existing dual stack nodes.

I hope not, but possibly that has to sy: unless they are deployed
on a mixed network along with IPv6-only stacks. At the least, they
will need to receive different configuration in that case.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 25 Jul 2008 22:51:53 +0200

> Sounds like the case you're talking about is a multi-homed client.

That was what I have in mind with regard to the failover part that I  
discussed before, but this has nothing to do with the text that you  
quoted...

> Since above we're talking about v6-only networks, but hosts with

I'm assuming it would be possible that all hosts share the same IPv6  
connectivity, but some also have IPv4 and others don't. Perhaps this  
isn't a very likely scenario; the easiest way to make this happen  
would be to give IPv4 over tunnels to some hosts but not others,  
presumably this wouldn't be a common configuration.

Then again, as an ISP you never know what your customers do on their  
networks, so it may or may not be safe to provide them with synthetic  
AAAA records.

> you can use a well-known range.

Right. If we want to put it far away from the client = make it a  
service that can be provided by a third party over the internet, we  
need some kind of authenication, which isn't in there now.

> a v4-only network), then you need a routable prefix.

That, too, yes.

> That's why I want pictures in the draft to see which scenarios you're

I guess I'll have to make some.  :-)

A few of us are presenting operational considerations for NAT64 etc in  
the ops area session.

> I'm not yet convinced that we need updates to existing dual stack  

You do if you want to run DNSSEC or IPsec over NAT64, and maybe if you  
want to have fast failover when a NAT64 fails.

> available, then you have to assume that most hosts won't have it.

Back in the day we gave users CDs with software they had to install to  
connect to the internet when they signed up for internet access. I  
don't think it's unreasonable to expect users who will be getting  
IPv6+NAT64 connectivity to install an OS patch.

> at least for the short term.

How short?

> Marcelo already answered this... existing hosts sort them after

Hm, despite my feature requests not all OSes that I use support the  
RFC 3484 policy table. (I guess if they can't even acknowledge, let  
alone fix, the fact that IPv6 packets larger than 2k can't be  
transmitted successfully over firewire, which leads to real-world  
breakage for normal use cases, then this one must be quite low on the  
list. I wasn't happy when another OS that I use simply removed  
firewire networking but at least that way users don't run into bizarre  
problems. On the remaining OSes that I use it never worked so at least  
there are no expectations.)
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 25 Jul 2008 23:01:08 +0200

On 25 jul 2008, at 7:23, Pekka Savola wrote:

> addresses, or choose something else altogether.  Given that you  
> can't depend on the existing behaviour of mapped addresses anyway,  
> if you go this "fixed address block" route, the least astonishing  
> failure modes could be achieved with a new special prefix.

Right.

> If you don't signal anything, the result is that you spew out  
> packets with the mapped addresses with the assumption that there is  
> going to be a translator somewhere along the path that's going to do  
> something to them.

Right.

> Otherwise they end up transiting enterprise and backbone networks  
> and potentially arriving at the destination which does something  
> unexpected

No, if there's no translator the packets won't end up at the  
destination because the mapped prefix isn't routed on the v6 internet.

> modifications to API calls.  As demonstrated, stack modifications  
> are already needed (at least in API handling), so why not do it all  
> the way?

Because I don't think we'll see those modifications in wide use by the  
time we neet NAT64. If we can do something reasonable with no  
modifications and something that's actually good _with_ modifications  
that is a much stronger deployment model than to require modifications  
before anything can happen. Then again, if there's strong consensus  
that the modifications can/will/should be made within a farly short  
time, we can do more.

> and a translator -- or, if there doesn't happen to be translator,  
> the packets would end up in the destination network. But maybe not..)

The source host would use a normal, global v6 address as the source,  
so no problem there, and a mapped address as the destination. This  
will either flow towards a translator or be dropped on the floor  
somewhere because there is no route for ::ffff:0:0/96. It won't reach  
the destination, because no _hosts_ have an IPv4 mapped address in its  
IPv6 form configured on an interface. The destination only sees IPv4  
addresses.

In the direction from the translator to the host you'll see the mapped  
source addresses but obviously, these packets will match previous  
outgoing packets so they can be filtered statefully.

> Internet is honest netizen?

Well, if you don't trust someone, don't give them your packets. This  
is the same whether or not they run a translator. Or you can apply  
HMAC protection in the form of IPsec or TLS so the untrusted network  
can no longer do bad things to your packets except make them disappear.
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Pekka Savola <[email-masked]>
Date: Sat, 26 Jul 2008 08:10:49 +0300 (EEST)

On Fri, 25 Jul 2008, Iljitsch van Beijnum wrote:
>> potentially arriving at the destination which does something unexpected
>
> No, if there's no translator the packets won't end up at the destination 
> because the mapped prefix isn't routed on the v6 internet.

If it's the destination address -- yes, but you might be surprised how 
widely default routes are being used.  Enterprise-ISP egress use them 
a lot.  Even smaller ISPs use them a lot.  With the number of routes 
climing, one resolution is using a default route (+well selected more 
specifics) -- it might even end up used in medium size ISPs.  The 
result is probably that packets end up looping between two routers at 
some ISP's backbone until the hop count rearches zero.

If it's the source address (it wasn't obvious whether this would be 
used, but apparently at least in translator->v6host direction), there 
is no check from this POV.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Jul 2008 18:14:50 +0100

> If it's the destination address -- yes, but you might be surprised  
> how widely default routes are being used.  Enterprise-ISP egress use  
> them a lot.

Right. But nobody configures mapped (or compatible) addresses on their  
host interfaces, and nobody puts them in their routers. So even if  
packets travel a long way by virtue of default routes, they're not  
going to be delivered to the right destination successfully unless  
there's a translator in the path that is set up to translate packets  
with these addresses.

> The result is probably that packets end up looping between two  
> routers at some ISP's backbone until the hop count rearches zero.

No, that generally happens when a customer has a prefix, such as a / 
22, but they only use part of it, like a /23. If they then don't  
filter out packets to the unused space (the other /23) the packets  
will flow back to the ISP through the default route and the packets  
loop.

In this particular case ISPs won't send these packets to customers.  
They'll follow default routes until they reach a router that doesn't  
have a default or until the packets are filtered.

> used, but apparently at least in translator->v6host direction),  
> there is no check from this POV.

Right, from a translator to a host the packets could be delivered if  
they're not (ingress) filtered.
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area