[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-v6ops-nap-01.txt
Fred - here are my comments on nap-01:
1) P.4, last sentence of next-to-last paragraph, change: "without address translation" to : "without IPv6 address translation".
2) P.8, last sentence of next-to-last paragraph, punctuation at end of sentence.
3) P.14, paragraph beginning: "This simple rule...". The first sentence in this paragraph is overly-long and I had trouble parsing it. The sentence should at least be subdivided with some attention to grammar.
Also, I am not sure about the assertion: "similar protection and security holes the typical IPv4 NAT device will offer" since the example firewall rules above speak of creating reflective (symmetric?) session state. If, by reflective session state, it means that the rule for inbound traffic will be identical to the rule for outbound traffic except with the source and destination portions reversed, then my understanding from other documents I have read is that this is not how the typical IPv4 NAT device works. (From what I have read, I have been led to believe that the typical IPv4 NAT device leaves some/all of the source portion for inbound traffic rules as wildcard match.)
I hope that reflective/symmetric is how it will work for NAP, since I have some concerns for security with the typical IPv4 NAT's wildcard match.
4) P. 15, last paragraph, change: "so that a NAT is not required" to: "so that IPv6 address translation is not required".
5) P. 16, second paragraph, change: "2^64 hosts" to: "2^64 addresses". I may have missed other examples throughout the document where "hosts" was used when "addresses" was intended.
6) P. 22, last paragaph, sentence beginning: "It should not even try...". This was another overly-long sentence that I found difficult to parse.
(My time to review the document was limited, and I did not have the chance to review the appendix sections.)
Fred
fred.l.templin@boeing.com
> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]
> Sent: Wednesday, June 15, 2005 1:33 PM
> To: 'v6ops@ops.ietf.org '
> Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt
>
>
> Gunter tells me that this draft was almost ready for
> submission when I
> issued the last call on the previous version. oops. Let's
> restart the
> last call today, reviewing this draft, and ending two weeks
> from today.
>
> On Jun 15, 2005, at 1:13 PM, Internet-Drafts@ietf.org wrote:
>
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the IPv6 Operations Working
> Group of the
> > IETF.
> >
> > Title : IPv6 Network Architecture Protection
> > Author(s) : G. Van de Velde, et al.
> > Filename : draft-ietf-v6ops-nap-01.txt
> > Pages : 31
> > Date : 2005-6-15
> >
> > Although there are many perceived benefits to Network Address
> > Translation (NAT), its primary benefit of "amplifying" available
> > address space is not needed in IPv6. In addition to NAT's many
> > serious disadvantages, there is a perception that other benefits
> > exist, such as a variety of management and security
> attributes that
> > could be useful for an Internet Protocol site. IPv6 does not
> > support
> > NAT by design and this document shows how Network Architecture
> > Protection (NAP) using IPv6 can provide the same or more benefits
> > without the need for NAT.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-01.txt
> >
> > To remove yourself from the I-D Announcement list, send a message to
> > i-d-announce-request@ietf.org with the word unsubscribe in
> the body of
> > the message.
> > You can also visit
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> >
> > Internet-Drafts are also available by anonymous FTP. Login
> with the
> > username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-ietf-v6ops-nap-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > mailserv@ietf.org.
> > In the body type:
> > "FILE /internet-drafts/draft-ietf-v6ops-nap-01.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility. To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command. To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader. Different MIME-compliant
> mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> --------------------------------------------------------------
> ---------
> > --
> > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
> >
> --------------------------------------------------------------
> ---------
> > --
> > In order to maintain computing infrastructure integrity,
> Cisco Systems
> > Enterprise Messaging Services and InfoSec teams have set a
> mail policy
> > disallowing executable attachments in email.
> >
> > This message contained an executable attachment type that
> is prohibited
> > by this policy. The attachment has been removed from this
> message and
> > copied to quarantine by our systems. It will be held in
> quarantine for
> > seven days in the event that the content needs to be retrieved.
> >
> > Please be aware many viruses attempt to look like
> legitimate email or
> > notifications from anti-virus systems. We will clearly mark a
> > seperation
> > between our notifications and the original email as follows:
> >
> > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION
> TECHNOLOGY"
> >
> > For further reference information about viruses and email antivirus
> > efforts within Cisco, please visit:
> >
> > http://wwwin.cisco.com/it/ems/services/antiviral
> >
> > If your concern isn't addressed by the information in this
> notification
> > or the above web page, you may open a support request:
> >
> > http://wwwin.cisco.com/support/
> >
> > Select "Messaging", "Email-Related", "Mail Routing"
> >
> > Please include in the text of your case the following information:
> >
> > * Full headers of the message. Documentation on displaying the full
> > headers is available at this URL:
> >
> > http://wwwin.cisco.com/support/library/faqs/solution002471.html
> >
> > * This unique quarantine identifier: j5FKITc4010679
> >
> > If the matter is urgent, you may follow up by calling one
> of the below
> > referenced numbers. Please make every effort to provide the above
> > requested information via the support web tool prior to
> calling as it
> > will greatly aid the resolution of your issue.
> >
> > Americas:
> > 1 408 526 8888
> >
> > Asiapac
> > +61 2 8446 8888
> >
> > EMEA
> > +31 20 485 4888
> >
> > Japan
> > +81 3 5549 6888
> >
> > US (Toll Free)
> > 1| 800| 888| 8187| (ext.68888)
> >
> > Thank you for your cooperation,
> >
> > Enterprise Messaging Services
> > Cisco Systems, Inc
> >
> > --OtherAccess--
>
>