Subject: [BEHAVE] Amount of fragmentation resulting from translation

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 29 Oct 2009 09:14:14 +0100

Hi,

Been looking at the stateless document and i see that when translating 
IPv4 packets into IPv6 packets, the recommendation is:

   However, when the IPv4 sender does not set the DF bit,the translator
   has to ensure that the packet does not exceed the path MTU on the
   IPv6 side.  This is done by fragmenting the IPv4 packet so that it
   fits in 1280 byte IPv6 packets, since that is the minimum IPv6 packet
   size.

(note that this was defined in this way in the original rfc2765, so this 
is not a change introduced in this version)

So, my question is whether this behaviour would not result is massive 
fragmentation. I mean, one could guess that 1500 byte long packet are 
fairly common, and that the defined behavour would imply fragmentation 
of all these packets for example.

Of course, the solution of this problem relies on the translator doing 
PMTUD for IPv6, which requires to store state and adds complexity.

(FWIW, i am operating under the assumption that we should use the same 
appraoch for stateless and stateful. Of course, we could also discuss 
that i.e. selecting a different appraoch for stateless than for 
stateful, so if anyone wants to comment on this it would also be relevant)

I thought this worth some discussion.

Comments?

regards, marcelo

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 29 Oct 2009 04:40:13 -0400

I believe you have a point since 1500 byte packets are common. I think the
last part of the recommendation is what is causing the confusion...

" This is done by fragmenting the IPv4 packet so that it
   fits in 1280 byte IPv6 packets, since that is the minimum IPv6 packet
   size."

If we keep just the

"   However, when the IPv4 sender does not set the DF bit, the translator
    has to ensure that the packet does not exceed the path MTU on the
    IPv6 side. "

should be okay. In other words, you just fragment if needed.

As far as PMTUD goes although it creates state, you need to remember such
values per outgoing interface and not really per NAT binding.

On 10/29/09 1:14 AM, "marcelo bagnulo braun" <[email-masked]> wrote:

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

---

From: Zhen Cao <[email-masked]>
Date: Thu, 29 Oct 2009 16:48:45 +0800

On Thu, Oct 29, 2009 at 4:14 PM, marcelo bagnulo braun
<[email-masked]> wrote:
> Hi,
>
> Been looking at the stateless document and i see that when translating IPv4
> packets into IPv6 packets, the recommendation is:
>
> (note that this was defined in this way in the original rfc2765, so this is
> not a change introduced in this version
>
> fragmentation. I mean, one could guess that 1500 byte long packet are fairly
> common, and that the defined behavour would imply fragmentation of all these
> packets for example.

xlate draft defines so because it only consider stateless translation,
so not appropriate to add state due to PMTU on the translator.

>
> Of course, the solution of this problem relies on the translator doing PMTUD
> for IPv6, which requires to store state and adds complexity.

In stateful translation, i think the state is trivial comparably.

> appraoch for stateless and stateful. Of course, we could also discuss that
> i.e. selecting a different appraoch for stateless than for stateful, so if
> anyone wants to comment on this it would also be relevant)
>

It turns out that the specification of fragmentation and mtu issues
requires much coordination between stateless and stateful documents.
That's why i suggested to have an individual document on those topics.

Regards
-Zhen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 Oct 2009 09:54:08 +0100

On 29 okt 2009, at 09:14, marcelo bagnulo braun wrote:

> So, my question is whether this behaviour would not result is  
> massive fragmentation. I mean, one could guess that 1500 byte long  
> packet are fairly common, and that the defined behavour would imply  
> fragmentation of all these packets for example.

Right. Of course most traffic is TCP which has PMTUD enabled so DF=1,  
but there is some TCP with DF=0 and UDP video streaming usually has ~  
1470 byte packets and DF=0.

The problem is that if you translate IPv4 packets with DF=0 and  
they're too big on the IPv6 side, an IPv6 router will send back a too  
big message, and if you translate that message to an IPv4 too big  
message it will probably be ignored because UDP protocols have to do  
their own PMTUD in IPv4 which they don't AFAIK, and in the case of TCP  
with DF=0 PMTUD was almost certainly turned off.

So in the case where the IPv6 MTU is smaller than the IPv4 MTU (and 20  
bytes for the difference between the v6/v4 header sizes) for packets  
with DF=0 you need to fragment. That means the only question is  
whether you simply always fragment, or track the PMTU on the IPv6 side  
and only fragment when necessary.

Since any IPv6 host needs to track the PMTU for any host it talks to  
anyway (if it wants to send > 1280 byte packets, at least) the state  
requirement doesn't seem very unusual so I would go for that. But  
maybe others would prefer the other choice.

> values per outgoing interface and not really per NAT binding.

No, it's per IPv6 destination address. Could be that one host that  
uses the translator can handle 1500 byte packets while another can  
only handle 1480 or 1280.

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 29 Oct 2009 05:26:28 -0400

Right, I was thinking about the directly connected case example in NAT64 but
if it is more than one hop away and there is no way of knowing the host's
attached link MTU you would need to keep on a per destination.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 29 Oct 2009 11:49:14 +0100

> so not appropriate to add state due to PMTU on the translator.

The difference between the stateless and the stateful is that the 
address translation requires state in one case and does not requires 
state in the other.
My understanding was the all the rest of the translation was the the same.
the issues about how to select the size of the outgoing packet has no 
relationship whatsoever with the state needed for the address 
translation afaict.

So i see this as being orthogonal to the issue of doing statefull or 
stateless translation.
OTOH, i don't have much problemwith defining different mechanisms for 
handling this for the stateless document and for the stateful document.

Regards, marcelo

---

From: Simon Perreault <[email-masked]>
Date: Thu, 29 Oct 2009 07:50:19 -0400

> of all these packets for example.

My take on this:

Yes 1500 bytes packets are common, but with DF=0 it means the end host is not
doing PMTUD. This means it should be ready to suffer the consequence of having
its packets be fragmented.

Do not do PMTUD in the host's stead. That would be too kind for its own good. ;)

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 29 Oct 2009 12:53:56 +0100

> Do not do PMTUD in the host's stead. That would be too kind for its  

It's not the host sourcing the > 1280 DF=0 packets that suffers if the  
translator fragments all those packets, but the translator and the  
receiver, which have to do extra work.

In my opinion, the preferred way to handle too bigs coming in on the  
IPv6 side of the translator is to handle them as a host would, i.e.,  
start sending smaller packets. This also avoids black holes when the  
IPv4 host sends packets with DF=1 but doesn't react to "too big"  
messages, which is all too common.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 29 Oct 2009 08:08:05 -0400

Iljitsch van Beijnum wrote, on 2009-10-29 07:53:
> start sending smaller packets.

How would the amount of work required of the translator and the receiver compare
to that of the current text?

Simon

---

From: Zhen Cao <[email-masked]>
Date: Thu, 29 Oct 2009 22:47:01 +0800

On Thu, Oct 29, 2009 at 6:49 PM, marcelo bagnulo braun
<[email-masked]> wrote:
>>> fairly
> The difference between the stateless and the stateful is that the address
> translation requires state in one case and does not requires state in the
> other.
> relationship whatsoever with the state needed for the address translation

I do not agree.  But we can solicit the authors of RFC2765 to answer
the question.

>From the definition in framework draft, stateless translation strictly
require there is not any state created by the translation algorithm.

Stateful Translation:  A translation algorithm may be said to
"require state in a network element" or be "stateful" if the
transmission or reception of a packet creates or modifies a data
structure in the relevant network element.

Stateless Translation:  A translation algorithm that is not
"stateful" is "stateless".  It derives its needed information
algorithmically from the messages it is translating.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 29 Oct 2009 15:35:58 -0700

> 1470 byte packets and DF=0.

A hybrid approach might be useful. E.g. if the IPv4 packet is translated
into an IPv6 packet > 1280, try to send it. If you get ICMP back, just
do 1280. Anyway, I think this should be left to the implementation.
Doing PMTUD would be good in my opinion, but alternatively, just assume
1280. Just like IPv6 hosts have to do.

> The problem is that if you translate IPv4 packets with DF=0 and they're 
> too big on the IPv6 side, an IPv6 router will send back a too big 
> message, and if you translate that message to an IPv4 too big message it 
> will probably be ignored because UDP protocols have to do their own 
> PMTUD in IPv4 which they don't AFAIK, and in the case of TCP with DF=0 
> PMTUD was almost certainly turned off.

Yes. I think if DF=0 you just have to fragment. You cannot assume PMTUD
will work. You still have the choice whether to do PMTUD or assume 1280
on IPv6 side of course.

> with DF=0 you need to fragment. That means the only question is whether 
> you simply always fragment, or track the PMTU on the IPv6 side and only 
> fragment when necessary.
> 
> requirement doesn't seem very unusual so I would go for that. But maybe 
> others would prefer the other choice.

Yes, I think it's OK doing PMTUD. But I still think it can be optional.
I prefer the additional state (if translator can cope with it) to having
all the extra fragmentation. Of course there will probably be some
issues due to some IPv4 senders sending 1500 byte packets, where the
IPv6 receiver is also likely to handle at most 1500.

Stig

> No, it's per IPv6 destination address. Could be that one host that uses 
> the translator can handle 1500 byte packets while another can only 
> handle 1480 or 1280.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Oct 2009 10:29:48 +1100

> IPv6 receiver is also likely to handle at most 1500.

I think turning on PMTUD in the middle of the network is just plain
wrong.  There are OS which incorrectly turn on PMTUD for IPv4 for
all packets.  This causes problems for applications like DNS servers.

There is only one choice and that is to fragment at network MTU.  Anything
else will cause operational problems.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Stig Venaas <[email-masked]>
Date: Thu, 29 Oct 2009 16:47:00 -0700

Mark Andrews wrote:
[...]
> else will cause operational problems.

I actually agree, see below.

I've seen some of those issues too. You do have a point. I think one
should only do IPv6 PMTUD if the IPv4 packet has DF set.

I think the issue with UDP and PMTUD is that the stack does not resend
the packet if "packet too big" (or equiv IPv4) is returned. So the
application would need to be triggered to send a new request. Otherwise
you just hang around waiting for an application retry.

The question is if the translator does PMTUD, should it then cache the
packets until PMTUD is successful? That is of course problematic. But
just dropping the packets on the floor in the middle of the network is
bad too.

I think this would be an issue if the translator were to do IPv6 PMTUD
when IPv4 DF is not set.

So if IPv4 DF is not set, better not do IPv6 PMTUD. Just assume PMTU
1280.

If IPv4 DF is set, then you can do PMTUD end to end, which I think is
fine.

Stig

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 29 Oct 2009 21:57:06 -0400

I find this email talking about IPv6 PMTUD issues and the following thread
very interesting. It contain very useful data.

[Ipv6-techsig] IPv6 PMTUD issues, some data

http://listserver.internetnz.net.nz/pipermail/ipv6-techsig/2009-October/0007
08.html

Although PMTUD is enabled by default but if it is not as reliable as hoped
fragmentation will be common within TCP connections. In that case it would
be massive fragmentation in the translator since TCP WebServer/Video traffic
is overwhelming and packets > 1280 are very common.

Thanks,

Reinaldo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 30 Oct 2009 09:18:36 +0100

> else will cause operational problems.
Just to be clear, you support the option that the translator always 
sends IPv6 packet of 1280 bytes rahter than the translator doing pmtud 
to figure out which is the mtu availbale for that path, correct?

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 30 Oct 2009 09:24:14 +0100

> If IPv4 DF is set, then you can do PMTUD end to end, which I think is

This is what the current stateless does.
I am reading that people still support this option, so unless we have 
strong oposition, i guess we should go this path

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 30 Oct 2009 09:34:30 +0100

Hi,

thank you very much for the pointer, this is interesting data i agree.

However, i am not sure i read it in the same way you do.

In particular, what i extract from this analysis is that there is a non 
negligible amount of IPv6 hosts/sites that filter the packet too big 
errors and simply send packets of 1280 bytes (about 15% if i read it 
correctly).

This actually affects other part of the fragmentation discussion and it 
is related to the the question about how to set the DF and the id field 
for ipv4 packets resulting from translating IPv6 packets wihtout the 
fragment header.

So, consider that the translator receives an IPv6 packet without a 
fragment header.
Those packets without the fragment header do not contain any ID value. 
The stateless document
defines that the ID value is set to 0 and the DF set to 1. That works 
modulo the
following black hole situation:
Suppose that an IPv6 site is configured to drop ICMP packet too big msgs 
and configure
its hosts to only send packet of 1280 bytes. That would work for any 
communication
with other IPv6 hosts, but it would break for a communication with an 
IPv4 host
behind a translator and sitting on a link with MTU smaller than 1280.
In order to solve this problem, we should set the ID value different for 
different
packets and set DF to zero. In order to do that, we should generate 
values for the ID
field so that they do not clash

That would require changing the stateless document or if we don't want 
to keep the seq number state in that document, but we consider the 
problem is real and want to solve it int he stateful case, then take a 
different approach in the stateless and the staefull document.

Comments?

regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 30 Oct 2009 11:01:48 +0100

> I am reading that people still support this option, so unless we  
> have strong oposition, i guess we should go this path

I prefer that the translator "terminates" PMTUD, this avoids  
unnecessary fragmentation and avoids some PMTUD black holes.

However, I'm in favor of leaving this up to implementers, I don't  
think we should require one solution or the other.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 30 Oct 2009 11:19:10 +0100

On 30 okt 2009, at 09:34, marcelo bagnulo braun wrote:

> In particular, what i extract from this analysis is that there is a  
> non negligible amount of IPv6 hosts/sites that filter the packet too  
> big errors and simply send packets of 1280 bytes (about 15% if i  
> read it correctly).

Actual PMTUD failures were only 9 out of 380 = 2.4%. All failures  
together were 12% (51 out of 423).

That isn't too terrible considering that IPv6 is rarely production  
quality yet.

(Note though that non-working IPv6 is often not much of a problem  
because most applications fall back to IPv4, but PMTUD failures are a  
big deal because there is no fallback.)

>> fragmentation will be common within TCP connections.

I don't see this...

For fragmentation to happen with TCP, you need:

1. The IPv4 host has to have a "large" MTU
2. The IPv6 host hass to have a "large" MTU
3. There must be a link with a "small" MTU on the IPv6 path
4. The IPv4 host has to set DF=0

Of course 1 and 2 are common. 3 is probably pretty common today  
because of tunnels, but assuming a NAT64 run by an ISP, it would make  
sense that the IPv6 path would be native so there is no reduction in  
MTU size along the IPv6 path. 4 is quite uncommon, although it does  
happen.

I'd say that these conditions will only hold in a fraction of a  
percent of all cases.

It would be more common for video streaming over UDP, though.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 30 Oct 2009 11:23:05 +0100

Iljitsch van Beijnum escribió:
>> big errors and simply send packets of 1280 bytes (about 15% if i read 
>> it correctly).
>
> Actual PMTUD failures were only 9 out of 380 = 2.4%. 
yes, but the author says:

In addition to the outright failures (PMTUD_FAILs), we believe that the
results RX_NODATA and RX_NOACK also indicate PMTUD failure. They could
result when the server's HTTP response packets are discarded somewhere
along the path for being too big and the server never learns that this
is occurring (and neither do we). The server's response packets are
disappearing into a PMTU black hole.

So, we are close to 31 of 371.

Anyway, i would liek to hear what people think whether we need to worry 
about this black holes or not

Regards, marcelo

> All failures together were 12% (51 out of 423).
>

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 30 Oct 2009 07:18:15 -0400

Inline....

> MTU size along the IPv6 path. 4 is quite uncommon, although it does

If IPV6 MTU on the IPv6 side of the translator is 1280 (proposed default
without PMTUD), IPv4 MTU on host is 1492, and DF=1, then the problem becomes
the number ICMP too big messages.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 30 Oct 2009 12:44:18 +0100

> the number ICMP too big messages.

Not sure why the IPv4 MTU would be 1492 and not 1500 (you would be  
inviting a world of hurt with that), but a 1280 MTU on the IPv6 side  
is a very bad idea for exactly the reason that you mention: now you  
have to send too big messages for pretty much every TCP session.

If the MTU on both sides of the translator is 1500, on the other hand,  
the TCP MSS option will make sure that IPv4 hosts send 1480-byte  
packets (1440 MSS + 20 bytes of IP + 20 bytes of TCP) which will then  
be translated into 1500-byte IPv6 packets and life is good.

This way, we only have to worry about packets with DF=0, as per the  
previous discussion.

Just in case anyone missed it: either fragment IPv4 packets with DF=0  
into max 1280-byte fragments in all cases, or act as an IPv6 host and  
track the PMTU of IPv6 destinations and fragment as necessary.

But for DF=1 you really want to be able to handle 1500-byte packets to  
avoid ugly hacks and/or unnecessarily triggering PMTUD black holes.  
(Although you must still be prepared to send back too bigs to IPv4  
hosts when the IPv6 host announces an MSS larger than 1440, which  
would happen if the IPv6 host has a local MTU larger than 1500.)

---

From: Mark Andrews <[email-masked]>
Date: Sat, 31 Oct 2009 00:20:29 +1100

> to figure out which is the mtu availbale for that path, correct?

Yes.

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 30 Oct 2009 12:30:33 -0400

It is the norm in on ADSL/PPPoE deployments.

Thanks,

On 10/30/09 4:44 AM, "Iljitsch van Beijnum" <[email-masked]> wrote:

> inviting a world of hurt with that),

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 30 Oct 2009 17:39:01 +0100

> It is the norm in on ADSL/PPPoE deployments.

But weren't we talking about the translator's MTU? I would assume  
those aren't hooked up to an ADSL link.

---

From: Stig Venaas <[email-masked]>
Date: Fri, 30 Oct 2009 10:00:36 -0700

Iljitsch van Beijnum wrote:
> But weren't we talking about the translator's MTU? I would assume those 
> aren't hooked up to an ADSL link.

The main issue is really that with the typical IPv4 end-point MTU, you
will need to fragment because of the increased size of the IPv6 header.
It doesn't help much with 1492. I would argue anyway that there are lots
of deployments where the IPv4 end-point MTU is 1500.

Stig

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 30 Oct 2009 18:14:58 +0100

> of deployments where the IPv4 end-point MTU is 1500.

The TCP maximum segment size option hides a multitude of sins.  :-)

IPv6 host with MTU = 1500
IPv4 host with MTU = 1500

IPv6 host sends SYN with MSS=1440 (1500 - 40 bytes IP - 20 bytes TCP)
IPv4 host sends SYN/ACK with MSS=1460 (1500 - 20 bytes IP - 20 bytes  
TCP)

This means that the IPv6 host will send packets that are 1500 bytes.  
Based on the IPv4 host's MSS it could send 1460 + 40 IP + 20 TCP =  
1520 bytes but since it has a 1500 MTU it will be sending 1500-byte  
packets which are translated into 1480-byte packets.

The IPv4 host will send packets that are 1480 bytes: 1440 bytes from  
the MSS + 20 IP + 20 TCP. These packets will be translated into 1500- 
byte IPv6 packets.

Note that PMTUD doesn't come into play here for TCP. Also note that  
nothing changes with an MTU of 1492 on the IPv4 side.

Other example:

IPv6 host with MTU = 9000
IPv4 host with MTU = 1500
Translator with MTUs = 1500

In this case, the IPv4 host will send 1500-byte packets which are  
translated into 1520-byte packets so the translator has to send an  
ICMP packet too big message if DF=1 to the IPv4 host, and fragment if  
DF=0.

So in this case there is an increased possibility of PMTUD black  
holes, but that is to be expected with a > 1500 MTU.

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 30 Oct 2009 13:46:42 -0400

I agree that many deployments where the MTU is 1500. The 1492 was just an
example of a type of MTU that is common in ADSL/PPPoE deployments.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 30 Oct 2009 19:27:11 +0100

> those aren't hooked up to an ADSL link.
why not?
you could put a nat64 in the cpe, right?

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 30 Oct 2009 14:37:45 -0400

Yes, it could. There was a discussion about NAT64 scenarios before and it
served to point out that people have different views on the deployment
scenarios. 

As far as the ISP running the NAT64, one could argue that even if the NAT64
is in the CPE, that is 'run by the ISP' as well. There was also a Microsoft
direct access scenario sent to the list.

Suggestion: 

My suggestion then was that the NAT64 document should have an
'applicability' section (was many RFCs have) so that it is clear the
scenarios the solution covers.

Personally I feel the NAT64 could be at the CPE or deeper within the
network. It could be run by the ISP or an Enterprise.

Thanks,

Reinaldo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 30 Oct 2009 19:45:09 +0100

> you could put a nat64 in the cpe, right?

Hm, wouldn't it be easier to do NAT44 like people do today if each  
customer CPE has its own IPv4 address? I would think NAT64 in an ADSL  
CPE would be an unusual situation.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 30 Oct 2009 19:45:15 +0100

The draft has section    8.  Application scenarios which describe the 
scenarios that are defined in the framework document that the nat64 
apply. Not sure if more is needed.
If you think it does, please propose text so that wg can comment.

Regards, marcelo

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 30 Oct 2009 15:00:24 -0400

Hi Marcelo,

Those scenarios are fine from the point of view of mapping to the framework
doc. But given the discussion we had/are having it seems to me that who runs
the GW and where it could be located in the network was not clear.

Small nit:

Section 8.2 is labeled as 'scenario 3'. There is no scenario 2.

> If you think it does, please propose text so that wg can comment.

Sure, something like (if there is consensus):

X. Applicability Statement

The GW could be located on the demarcation point between the ISP and its
customer or deeper within the ISP network. When the GW is located within a
CPE it could be managed by the customer or the ISP.

note: 'CPE' here should not be seen only as a small modem Home network, but
anything from a home network, SOHO till full fledge enterprise.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 30 Oct 2009 20:15:24 +0100

On 30 okt 2009, at 19:45, marcelo bagnulo braun wrote:

> The draft has section    8.  Application scenarios which describe  
> the scenarios that are defined in the framework document that the  
> nat64 apply. Not sure if more is needed.

A stateful NAT64 can be deployed anywhere wwhere there is a globally  
routable IPv4 address available for use by the translator and there is  
an IPv6 path towards the hosts that are served by the translator.

Secondary considerations are:

- paths with at least a 1500-byte MTU to both the IPv6 hosts served by  
the translator and the IPv4 internet are highly recommended

- the ability to provide the IPv6 hosts served by the translator with  
DNS resolver addresses that point to the DNS64 (through DHCPv6 or RFC  
5006)

- the ability to restrict access to the IPv6 side of the translator by  
filtering addresses (i.e., if IPv6 source addresses can be spoofed the  
translator may be abused to hide attacks towards third parties)

Deployment within an ISP network or a reasonably sized enterprise  
network will easily accommodate all of the above. Deployment in a SOHO  
environment or across the public internet is not impossible, but does  
require compromises and/or extra complexity.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Oct 2009 14:58:13 +1300

On 2009-10-31 02:20, Mark Andrews wrote:
>> Mark Andrews escribi�:

BTW, the MTU data observed in draft-defeche-ipv6-traffic-in-p2p-networks
strongly support this for today's IPv6 world. Average observed IPv4
MTU was 1498 bytes and average observed IPv6 MTU was 1289, obviously
telling us that 1280 is the dominant value in practice (at least
for hosts running BitTorrent). So it's not only the safe value to use,
but it's also not very sub-optimal.

   Brian

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 30 Oct 2009 22:34:19 -0400

This seems like a good summary, including the secondary considerations.

One suggestion:

I would change the following text by removing references what is Internet
and what is network.

Change:

"- paths with at least a 1500-byte MTU to both the IPv6 hosts served by
the translator and the IPv4 internet are highly recommended"

To: 

" paths with at least a 1500-byte MTU to both the IPv6 and IPv4 hosts served
by the translator are highly recommended"

Since there are scenarios in the NAT64 doc and framework where the
'Internet' is IPv6 and IPV4 is a network.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 31 Oct 2009 10:18:08 +0100

> but it's also not very sub-optimal.

Disagree.

I've been looking at IPv6 in BitTorrent a bit, and nearly all peers  
participating in BitTorrent over IPv6 use 6to4. Obviously there will  
be little overlap between 6to4 users and NAT64 users...

I'll see if I can dig up some info from people visiting my websites  
over IPv6.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 01 Nov 2009 09:00:55 +1300

On 2009-10-31 22:18, Iljitsch van Beijnum wrote:
> participating in BitTorrent over IPv6 use 6to4. Obviously there will be
> little overlap between 6to4 users and NAT64 users...

Actually draft-defeche shows that Teredo is twice as important as 6to4,
but yes, most of the 1280s come from automatic tunnels. But I don't get
your argument: if the PMTU is limited to 1280 anywhere in the IPv6 domain,
it's a problem, for some of the deployment scenarios for
draft-ietf-behave-v6v4-xlate.

> 
> I'll see if I can dig up some info from people visiting my websites over
> IPv6.

Yes, that would be valuable.

   Brian