RE: I-D Action:draft-daley-ipv6-nonat6-00.txt

[Greg Daley <hoskuld@hotmail.com>]

Hi Brian,

Thanks for reading what is still a very rough draft.

This draft was primarily born out of the discussions at last IETF meeting,
where several of the listeners were confused about how new IPv6 NAT tasks
were being justified in terms of the services required.

There was a lot of discussion about (non-port based) NAT operations.  This
document seeks to clarify how these functions would actually work, and how
alternatives would also work.

The role of alternatives here is not to entrench a proliferation of ideas,
but to show that the alternatives can be a complete replacement for NAT
operations within the network.

The relationship with RFC4864 is not delineated clearly, and I will have
to work on the references which were poorly constructed.  I apologize.

I will see how I can identify the relationship, and the goals of this draft
early in the Introduction.

One of the solutions shown for Network Topology hiding (the Tunneled Services)
could be implemented as a Mobile IPv6 service.

Personally, I do not think this will be a successful deployment model because of
the heavy implementation load (IPSec, dynamic movement/change detection, home
movement considerations) which would be required for deploying the endpoint/Mobile Node.
It is more likely that a simple IPv6-in-IPv6(or UDP) tunnel, with a gateway discovery
advertisement would meet the local network's address binding need, because it would be
more universally implemented.

As such, I have stuck closer to  more theoretic tunnelled approach as described
in the 6ai BoF.  I would be very happy if everyone just used MIPv6 though.

Once again, sorry for rushing this out.  There was a set of analysis in the
document which I thought made the distinction between NAT's Goals and operations
clearer, and I didn't want to let the meeting pass without sending it to the
ether.

I will try to fix some of the structural and reference issues, and see if there
is a solid contribution.

Thanks again,

Greg Daley



----------------------------------------
> Date: Sun, 12 Jul 2009 16:55:37 +0100
> From: brian.e.carpenter@gmail.com
> To: hoskuld@hotmail.com
> CC: v6ops@ops.ietf.org
> Subject: Re: I-D Action:draft-daley-ipv6-nonat6-00.txt
>
> Hi Greg,
>
> I'm not sure I understand your citation of RFC4864 in this draft:
>
>> Until now, NATs have only existed for IPv4, and for transitioning
>> from an IPv6 network to an IPv4 network [RFC2766][RFC4864].
>
> The whole point of 4864 was to identify the claimed benefits of NAT
> and discuss how IPv6 can provide them without NAT. It's certainly
> relevant to your draft, but I think it would be useful to be explicit
> about which parts of the gap analysis in 4864 you are addressing,
> and about whether 4864 missed part of the gap. It doesn't use the
> phrase "address independence" but does cover
> Privacy and Topology Hiding,
> Independent Control of Addressing in a Private Network
> Global Address Pool Conservation
> Multihoming and Renumbering with NAT
>
> Note, I'm not particularly disagreeing with your draft, I just think
> it could be better explained how it fits with the RFC4864 gap analysis.
>
> We also suggested some possible directions for topology hiding
> in 4864, including using Mobile IP tunnels on larger sites.
> I'm not sure we need any new mechanisms.
>
> Regards
> Brian
>

_________________________________________________________________
Looking for a place to rent, share or buy this winter? Find your next place with Ninemsn property
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Edomain%2Ecom%2Eau%2F%3Fs%5Fcid%3DFDMedia%3ANineMSN%5FHotmail%5FTagline&_t=774152450&_r=Domain_tagline&_m=EXT