Good thread. That was quick research into the Privacy draft Tim! It sounds like we are all pretty much in agreement that:
*) generating private link-local addresses is a bad idea, and neither the RFC or new Draft say to do it *) generating private ULA's does make sense, just like private global's makes sense (if desired by local administrators) *) I see in the Draft where it says local administrators should be able to disable privacy extensions by prefix, so privacy addresses could be generated for, say, global but not ULA-scope addresses, or as local administrators deem appropriate. I like choices. Thanks. John Spence ---------------------------------------------------- John Spence, CCSI, CCNA, CISSP Native6, Inc. IPv6 Training and Consulting [EMAIL PROTECTED] (wk) 206-682-0275 www.native6.com ---------------------------------------------------- >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of [EMAIL PROTECTED] >Sent: Wednesday, January 04, 2006 12:23 PM >To: [EMAIL PROTECTED] >Cc: [email protected] >Subject: (no subject) > >Accidentally left original subject: out of original reply; >sorry about that. Comments in-line: > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of Christian Huitema >Sent: Wednesday, January 04, 2006 3:20 AM >To: [EMAIL PROTECTED]; [EMAIL PROTECTED] >Cc: [email protected] >Subject: RE: (no subject) > >Hosts are not supposed to make any distinction between ULA and >global scope addresses. > >-> "not supposed to" seems a bit strong. Section 4.5 of RFC >4193 says "Application and other higher level protocols CAN >(capitalization mine) treat Local IPv6 addresses in the same >manner as other types of global unicast addresses." Again, in >section 1 "-In practice, applications MAY (capitalization >mine) treat these addresses like global scoped addresses." >Also, "In some cases, it is better for nodes and applications >to treat them differently from global unicast addresses. >Hosts autoconfigure ULA addresses if the RA advertises and ULA prefix. > >-> 'if' being the operative word (they could also be assigned >via DHCPv6 or manually). > >Thus, hosts that are programmed to generate RFC 3041 addresses >for global scope addresses will do the same for ULA. > >-> I just read draft-ietf-ipv6-privacy-addrs-v2-04.txt***, and >see that it includes references to ULAs. It also refers to the >ULA spec as informative, which was at the time also a draft. >If the draft*** becomes an RFC (which I expect it will), thus >obsoleting RFC 3041, it is then it would be appropriate to say >hosts "will do the same for ULA". At present (RFC 3041, not >RFC 4193) it does not mention ULAs. It's only appropriate to >cite drafts as "works in progress". > >Best Regards, > >Tim Enos >1Sam16:7 > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf >Of >> [EMAIL PROTECTED] >> Sent: Tuesday, January 03, 2006 8:14 PM >> To: [EMAIL PROTECTED] >> Cc: [email protected] >> Subject: (no subject) >> >> Hi John, please see my comments in-line: >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf >Of >> John >> Spence >> Sent: Monday, January 02, 2006 12:23 PM >> To: [email protected] >> Subject: Are privacy extensions, RFC 3041,defined for non >global-scope >> addresses? >> >> >> I re-read the document, and it certainly focuses on the >privacy needs >> of global-scope addresses. I did not find a place where it said it >> was not defined for ULA or link-local scope addresses. >> >> -> AFAICS, RFC 3041 deals only with global-scope addresses. >The stated >> goals (2-4) explicitly refer to global-scope addresses. >> >> Is that the intent - not defined for non global-scope addresses? >> Or I am reading that into it? >> >> -> I think it's reasonable to conclude the mechanism defined in RFC >3041 >> is not defined for non global-scope addressses. ULAs to my knowledge >> didn't exist at the time 3041 was written (RFC 3041 in January 2001, >RFC >> 4193 not until October 2005). Even though there is an extant draft >meant >> to update 3041 [draft-ietf-ipv6-privacy-addrs-v2-04.txt], it has yet >to >> become an RFC itself. >> >> -> If by some stretch RFC 3041 was meant for link-local scope >addresses, >> it seems that would be suboptimal. At least as often as the >temp link- >> local unicast address changed, the node would have to >(un)subscribe to >the >> corresponding solicited-node multicast group(s). That could lead to >> reduced performance. I'd also wonder about the affect temporary >link-local >> addresses would have on a router's neighbor cache, and/or any >connectivity >> dependent upon the accuracy of cache entries... How might this affect >ND >> itself (not a leading question BTW)? >> >> Thanks. >> >> -> Best regards, >> >> Tim Enos >> 1Sam16:7 >> >> ---------------------------------------------------- >> John Spence, CCSI, CCNA, CISSP >> Native6, Inc. >> IPv6 Training and Consulting >> [EMAIL PROTECTED] >> ---------------------------------------------------- >> >> >> >> ----------------------------------------------------------------- --- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> ----------------------------------------------------------------- --- >> >> >> ----------------------------------------------------------------- --- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> ----------------------------------------------------------------- --- > >---------------------------------------------------------------- ---- >IETF IPv6 working group mailing list >[email protected] >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >---------------------------------------------------------------- ---- > > >---------------------------------------------------------------- ---- >IETF IPv6 working group mailing list >[email protected] >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >---------------------------------------------------------------- ---- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
