Subject: [BEHAVE] Comments on draft-denis-behave-v4v6exthdr-00

From: Dave Thaler <[email-masked]>
Date: Fri, 7 Nov 2008 14:22:53 -0800

Some comments:

1) The document learns the external (IPv4) address of a NAT64, which may not
be the address seen by the other end of communication.  Specifically, there
could be a NAT44 between the NAT64 and the other end.  As such, since most
applications that need to know the external address need to know the one
from the farthest away layer of NAT (closest to the other end) instead of the
closest, the desire get the address seen by the closest one should be
justified.

2) This document proposes a mechanism for "Unilateral Self-Address Fixing"
as defined in RFC 3424 and hence the considerations in section 4 apply.

3) UDP and UDP-Lite are mentioned in section 4 but there is no discussion
of how to deal with them in section 3.1.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rémi Denis-Courmont
> Sent: Monday, October 20, 2008 6:57 AM
> To: [email-masked]
> Subject: Re: [BEHAVE] New Version Notification for draft-denis-behave-
> v4v6exthdr-00
>
> FYI - comments most welcome:
> http://www.ietf.org/internet-drafts/draft-denis-behave-v4v6exthdr-
> 00.txt
>
> On Monday 20 October 2008 16:32:43, you wrote:
> > A new version of I-D, draft-denis-behave-v4v6exthdr-00.txt has been
> > successfuly submitted by Remi Denis-Courmont and posted to the IETF
> > repository.
> >
> > Filename:      draft-denis-behave-v4v6exthdr
> > Revision:      00
> > Title:                 IPv6 destination header option for IPv4
> translator mapping
> > notification Creation_date:    2008-10-17
> > WG ID:                 Independent Submission
> > Number_of_pages: 13
> >
> > Abstract:
> > This memo defines a new IPv6 Destination header option to convey the
> > transport mapping information from an IPv4-IPv4 protocol translator
> > to the IPv6 end of a protocol-translated packet flow.
>
> --
> Rémi Denis-Courmont
> Maemo Software, Nokia Devices R&D
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 10 Nov 2008 10:12:24 +0200

On Saturday 08 November 2008 00:22:53 ext Dave Thaler, you wrote:
> Some comments:
>
> 1) The document learns the external (IPv4) address of a NAT64, which may
> not be the address seen by the other end of communication.  Specifically,
> there could be a NAT44 between the NAT64 and the other end.  As such, since
> most applications that need to know the external address need to know the
> one from the farthest away layer of NAT (closest to the other end) instead
> of the closest, the desire get the address seen by the closest one should
> be justified.

There are two different ways a NAT44 could be between the NAT64 and the remote 
end. If it's in "front" of the remote end, which should be a fairly common 
case, I think this is non-issue. On the other hand, if the NAT64 is nested 
with a NAT44, then, you're right that there is a limitation.

We can always extend the mechanism... especially, we can define an IPv4 option 
equivalent to this... but I am not so sure about the deployability of such 
thing. More importantly, it won't cope with a legacy/current NAT44 anyway.

Thanks