Thanks, Dan!!
I'll see if I can get another update done to fix your changes before
the final draft cut-off.
Margaret
On Oct 18, 2010, at 6:43 PM, Dan Wing wrote:
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf
Of Margaret Wasserman
Sent: Monday, October 18, 2010 12:05 PM
To: NAT66 HappyFunBall
Subject: [nat66] Fwd: New Version Notification for draft-mrw-nat66-00
Hi All,
I just submitted a new version of the NAT66 draft (see below). This
one includes a NAT66 algorithm for prefixes longer than /48.
I also changed the name of the document to remove the pointer to the
behave WG, and I updated my contact information.
Comments?
If you haven't already, please drop an email to [email protected]
asking for a tombstone for draft-mrw-behave-nat66 pointing to your
new draft. I know a lot of existing references to the old draft and
it would be good if they followed to the new draft.
side-by-side diff,
http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-mrw-behave
-nat66-02.txt&url2=http://tools.ietf.org/id/draft-mrw-nat66-00.txt
or http://tinyurl.com/2fg6rj4
Nit: very bottom of Section 8 says "described below"; better would
be a
forward
reference to the specific section number.
The new section 9 says:
Although any 16-bit portion of an IPv6 IID could contain 0xFFFF, an
IID of all-ones is a reserved anycast identifier that should not be
used on the network [RFC2526].
So, that's saying "a non-0xFFFF pattern will exist somewhere."
If a NAT66 device discovers a packet
with an IID of all-zeros while performing address mapping, that
...........^^^^^^^^^^^^^^^^
Is "all-zeros" intended here, or "all-ones"? Is all zeros a problem?
packet MUST be dropped, and an ICMPv6 Parameter Problem error SHOULD
be generated [RFC2463].
Nit: it might be helpful if section 8 and 9 were subsections below a
general
'algorithm' section, something like:
8. IP Address Mapping Algorithms
8.1. Prefixes shorter than /48
8.2. Prefixes longer than /48
At end of first paragraph of Section 12 ("A Note on Port Mapping")
it might
be useful to add a reference to RFC3022 which defines Network
Address and
Port
Translator (NAPT).
-d
Margaret
Begin forwarded message:
From: IETF I-D Submission Tool <[email protected]>
Date: October 18, 2010 2:49:17 PM EDT
To: [email protected]
Cc: [email protected]
Subject: New Version Notification for draft-mrw-nat66-00
A new version of I-D, draft-mrw-nat66-00.txt has been successfully
submitted by Margaret Wasserman and posted to the IETF repository.
Filename: draft-mrw-nat66
Revision: 00
Title: IPv6-to-IPv6 Network Address Translation (NAT66)
Creation_date: 2010-10-18
WG ID: Independent Submission
Number_of_pages: 15
Abstract:
This document describes a stateless, transport-agnostic IPv6-to-IPv6
Network Address Translation (NAT66) function that provides the
address independence benefit associated with IPv4-to-IPv4 NAT
(NAT44)
while minimizing, but not completely eliminating, the problems
associated with NAT44.
The IETF Secretariat.
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
