Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-30 Thread Tim Chown
On 29 Apr 2013, at 20:39, Ray Hunter v6...@globis.net wrote: Christian Huitema wrote: The problem here is that don't have all the names/IDs we'd like. For example, using the MAC address as the Interface_ID would do for this purpose... but the the IPv6 address is tied to the MAC address, and

I-D Action: draft-ietf-6man-addr-select-opt-10.txt

2013-04-30 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Distributing Address Selection Policy using DHCPv6 Author(s) : Arifumi Matsumoto

Re: AD Evaluation: draft-ietf-6man-addr-select-opt

2013-04-30 Thread Arifumi Matsumoto
Brian, thank you for your review. I posted a revision to reflect your suggestions. Regarding the section 3, I changed several sentences, to reduce implementors' confusion, and to serve better for uniform implementation behavior. Best regards, A new version of I-D,

[6man] #1: Proper source for an Interface Identifier

2013-04-30 Thread 6man issue tracker
#1: Proper source for an Interface Identifier Version -06 of the document includes the interface index in the expression F() that generate the stable privacy IIDs. It has been noted that interface indexes might not be stable, and that, in any case, mandating a specific source for tan

Re: Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-30 Thread Ray Hunter
Tim Chown wrote: On 29 Apr 2013, at 20:39, Ray Hunter v6...@globis.net mailto:v6...@globis.net wrote: Christian Huitema wrote: The problem here is that don't have all the names/IDs we'd like. For example, using the MAC address as the Interface_ID would do for this purpose... but the the

[6man] #2: Description of issues with traditional SLAAC addresses (embedding IEEE identifiers)

2013-04-30 Thread 6man issue tracker
#2: Description of issues with traditional SLAAC addresses (embedding IEEE identifiers) Some folks have noted that this I-D should clarify what are the issues with traditional SLAAC addresses (addresses that embed link-layer addresses). This is deemed as key to clarify which of them are

RE: Last Call: draft-ietf-6man-stable-privacy-addresses-06.txt (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard

2013-04-30 Thread Hosnieh Rafiee
Philipp, I didn't really want to continue this debate as I have repeatedly stated my views in my past responses, but if you like, I will once again explain it from my point of view. you seem to argue that privacy can only be mentioned if the protection is absolute. No, absolute is too a big

Re: Last Call: draft-ietf-6man-stable-privacy-addresses-06.txt (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard

2013-04-30 Thread Fernando Gont
On 04/30/2013 12:38 PM, Hosnieh Rafiee wrote: No, absolute is too a big word to use but the definition of the relative is also much different than when using it in reference to security. Unlike security where you can provide relative security through the protection of one protocol and then

RFC 6935 on IPv6 and UDP Checksums for Tunneled Packets

2013-04-30 Thread rfc-editor
A new Request for Comments is now available in online RFC libraries. RFC 6935 Title: IPv6 and UDP Checksums for Tunneled Packets Author: M. Eubanks, P. Chimento, M. Westerlund Status: Standards Track

RFC 6936 on Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums

2013-04-30 Thread rfc-editor
A new Request for Comments is now available in online RFC libraries. RFC 6936 Title: Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums Author: G. Fairhurst, M. Westerlund