Subject: Re: [BEHAVE] NAT66: my conclusions

From: Margaret Wasserman <[email-masked]>
Date: Mon, 1 Dec 2008 11:16:22 -0500

On Nov 30, 2008, at 7:23 PM, Keith Moore wrote:
>> 1. A stateless 1-to-1 checksum-proof NAT breaks referrals.
>
> this actually doesn't exist, because nothing says that all transport
> protocols have to use the same kind of pseudo-header or checksum.
>
This is absolutely true.  The goal of the checksum correction in NAT66  
is to avoid having to touch the TCP, UDP and ICMPv6 checksums which  
contain an IPv6 pseudo-header checksum (a 16-bit one's complement  
sum).  It will work for any transport layer that includes the IPv6  
addresses in a 16-bit one's complement checksum and will have no  
benefit (or detriment) for transport layers that don't.

Margaret

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 01 Dec 2008 18:13:44 -0500

>>>>> "Iljitsch" == Iljitsch van Beijnum <[email-masked]> writes:
    Iljitsch> After having debated the virtues of having NAT66 in the
    Iljitsch> first place and its features if we were to have it, my
    Iljitsch> conclusion is that we're not going to be able to create a
    Iljitsch> NAT66 specification that makes all parties happy enough to
    Iljitsch> reach rough consensus.

  As one who would like to have no NAT66 (I believe in SHIM6, ULA-like
objects, and better implementations of source address selection) I would
like to know the details of where the NAT66 people diverge.

  My opinion is that it would be useful to have 1 or 5 documents that
explains the requirements that people think they have.

  My impression is that we can't figure out if anything would be
acceptable, because we don't know what the assumptions each party has
made.

    Iljitsch> For a while I thought it would be a good compromise to
    Iljitsch> standardize one of these less nefarious NAT66s in order to
    Iljitsch> avoid ending up with the really bad ones. But after the
    Iljitsch> discussion the past few weeks my conclusion is that this
    Iljitsch> isn't going to work.

  I see. I believed what you did.

    Iljitsch> However, I believe there is something useful that the IETF
    Iljitsch> can do, and that is mostly what the BEHAVE wg has already
    Iljitsch> been doing: document NAT behavior, and create
    Iljitsch> specifications for applications that want to work through
    Iljitsch> those NATs.  But with IPv6 we have the opportunity to be
    Iljitsch> proactive: rather than describe the harm that existing
    Iljitsch> NATs do, BEHAVE could publish a document that describes
    Iljitsch> the various ways IPv6 NATs could be implemented, and then
    Iljitsch> order these in order of increasing harm, outlining the

  I think that this will become the document which you say will cause
more harm than good.

    Iljitsch> harmful effects each type of NAT66s would have.  Along
    Iljitsch> with some easy to understand terminology or numeric
    Iljitsch> ranking, this would allow application vendors to
    Iljitsch> communicate what types of NAT their products will work
    Iljitsch> with and which they won't, and allow end- users to specify
    Iljitsch> to their middlebox vendors what kind of NAT they want to
    Iljitsch> buy.

  Yes.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave