Re: [BEHAVE] How to set the DF and the ID values for IPv4 packets (was Re: Amount of fragmentation resulting from translation

[Reinaldo Penno <rpenno at juniper.net>]

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.

On 10/30/09 12:15 PM, "Iljitsch van Beijnum" <iljitsch at muada.com> wrote:

> 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.
>> If you think it does, please propose text so that wg can comment.
> 
> 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.