From alexandru.petrescu@gmail.com Thu Aug 4 03:23:02 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C80F21F8A58 for ; Thu, 4 Aug 2011 03:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2vqP6GYKa0G for ; Thu, 4 Aug 2011 03:23:01 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 28A0B21F87C9 for ; Thu, 4 Aug 2011 03:23:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p74ANDmP014174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Aug 2011 12:23:13 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p74ANCA0021305; Thu, 4 Aug 2011 12:23:13 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010183.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p74ANCac006263; Thu, 4 Aug 2011 12:23:12 +0200 Message-ID: <4E3A7310.7090001@gmail.com> Date: Thu, 04 Aug 2011 12:23:12 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Ipv Subject: Re: comments on draft-lynn-6man-6lobac-01 "IPv6 over MS/TP" (was: comments on ipv6-over-mstp) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 10:23:02 -0000 Hello Kerry, Sorry for late reply. I do agree with your comments and my comments below are non-blocking on the advancement of this draft. I support advancement of this draft. > On Tue, Jul 26, 2011 at 6:03 PM, Alexandru Petrescu > wrote: >> >> Comments on draft draft-lynn-6man-6lobac-00: >> >> - needs a section on multicast address mapping; it may not be >> straightforward: it may need to _not_ send all ip-multicasted >> messages to 255 link-layer address: the solicited-node multicast >> address includes the octet address (as opposed to eg ethernet >> 6octets) hence it could send it to that octet address (not 255). > > The current version is -01; see section 9 Yes, I mistakenly looked at -00 because that's how it was announced by the url in the meeting agenda - I just clicked on it. -01 addresses my initial comment of needing a multicast section. > It is a non-goal (perhaps this should be stated explicitly in the > I-D) to modify the current MS/TP state machines (other than the > extension for larger data frames already proposed in BACnet). I agree, it sounds difficult to modify the MS/TP state machines and I do not suggest that. I suggest modifications to the IP stack, instead. > The only currently available option is 255 (all-nodes). We *could* > look at MS/TP as a multicast challenged data link and support > functions like NS via RFC 4861 extensions as discussed in IPv6 ND > Optimization for Energy-aware Devices. sure, one could. > Plan B would be to look at using the 128-254 address range for > multicast mapping, but then we diverge from co-existence and > possibly need to modify state machines. Right, no, I don't suggest modify state machines below IP, but modify IP stack to better support broadcast of MS/TP yes. When the IP stack sends an NS to the solicited node multicast address it puts the last byte of the dst field of the IP header as a value 1..127. Then it builds the MAC header. What should be the dst address in that MAC header? (it is the IP stack who sets this field). Then draft-lynn-6man-6lobac-01 says: > MS/TP does not support multicast, therefore IPv6-level multicast > packets MUST be carried as link-layer broadcast frames in MS/TP > networks. This means that the dst field of the MAC header is 255 to answer the question. I think this unnecessarily sends a IP-multicast packet to everyone else on the link (255). This is probably not necessary. The IP stack knows the link-layer address (that one octet) and it should use it rather than 255 as the dst field of the MAC header. Typically NS with a sol-node IP dst address is used during DAD: try to see whether somebody else uses IP same address. For Ethernet, only 3 out of 6 bytes of the mac address are present in the IP sol-node address, hence it is necessary on Ethernet to have dst of the MAC header to be the multicast MAC address (or sometimes broadcast on Ethernet). But for MS/TP it seems only one octet is the unicast address, and that does fit in the IP sol-node address, and hence could be reused to be put in the dst address of the MAC header. Finally, this is just to make things smart, not necessarily a blocking point. >> - 1 Poll for Master - sounds as RS, why not mapping one into >> another? 2 Reply to Poll for Master sounds as RA, same. > > These are MAC control frames that are part of token generation (or > recovery from a lost token). Again, modification of the MS/TP MAC > is a non-goal. See section 2 for MS/TP MAC requirements. I agree modifying MS/TP MAC is a non-goal. Making a stack work ok on some link involves often address mapping but sometimes also message mapping, i.e. send an RS, and send "Poll for Master" at the same time. This is what some implementations (not MS/TP, other link) do, and this is what implementer needs to know. Message sending mapping is a rule like this: "Send RS MUST trigger Send "Poll for Master"." >> - MLD mapping could be as well useful. > > > > Can you say more about this? MLD is Multicast Listener Discovery protocol used typically to make multicast work on links, and sometimes on links not supporting link-layer multicast. Multicast to work ok is absolutely necessary for ND. In a similar vein as "send RS trigger send PFM", one could write rules like "send MLD REPORT to joing group of MASTERS prior to send PFM". These last two comments on message mapping and MLD are again just comments, non blocking. I look forward to advancement of this draft. Alex > > Thanks, -K- From alexandru.petrescu@gmail.com Thu Aug 4 10:04:35 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CB921F8B22 for ; Thu, 4 Aug 2011 10:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USXBFU7Ty8xq for ; Thu, 4 Aug 2011 10:04:34 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id BFE6E21F8B17 for ; Thu, 4 Aug 2011 10:04:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p74H4it1025150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Aug 2011 19:04:44 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p74H4hEc029752; Thu, 4 Aug 2011 19:04:44 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010183.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p74H4h4i012652; Thu, 4 Aug 2011 19:04:43 +0200 Message-ID: <4E3AD12B.7000006@gmail.com> Date: Thu, 04 Aug 2011 19:04:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: jonhui@cisco.com, Jari Arkko Subject: Re: AH over RH new type of RPL (was: Comment on rpl-routing-header draft) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ipv X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 17:04:35 -0000 Hello Jonathan, Jari, IPv6 WG, Please allow me to take advantage of this discussion to mention security of this new type of routing header. RFC 4302 "AH" knows RHs but not this new type of RH. It may be valuable to have an appendix which shows an example of how the AH over this routing header works, in a step-by-step manner: (currently, the draft does say algorithm to process RH but does not say how it should be recomputed at receiver to be re-covered by AH for checking). > A -> B -> C -> D -> E > > A -> B: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | B | 3 | C | D | E | > > B -> C: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | C | 2 | B | D | E | > > C -> D: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | D | 1 | B | C | E | > > D -> E: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | E | 0 | B | C | D | > > When the packet arrives at E, recreate the original RH4 header for MAC computation: > > n = ((Hdr Ext Len * 8) - Pad) / (16 - Comp) > tmp = Dst > Dst = RH4.A[0] > RH4.Seq = n > for (k = 1; k < n; k++) > { > RH4.A[k-1] = RH4.A[k] > } > RH4.A[k] = tmp > > |Src|Dst|RH4 | > | | |Seq|L0 |L1 |L2 | > ------------------------- > | A | B | 3 | C | D | E | References: RFC 4302 "AH" knows RHs but not this new type of RH. Discussion, email credit Robert Cragie http://www.ietf.org/mail-archive/web/ipv6/current/msg13769.html April 2nd, 2011 http://www.ietf.org/mail-archive/web/roll/current/msg05418.html September 10th, 2010 > Hi Jari, > > Thanks for the review. As you did below, I too need to apologize for > the delay in responding. See my responses below: > > On Jun 10, 2011, at 3:46 PM, Jari Arkko wrote: > >> I have reviewed this draft. >> >> I have a number of comments, most of which are at this point >> questions and discussion items. The comments are included below in >> three categories: technical comments, editorial comments, and >> comments relating to feedback from other people that may not been >> fully handled yet. In general, the draft is well written and >> largely ready to move to a Proposed Standard RFC. However, there >> are a couple of issues that we need to discuss: MTU requirements, >> recommendations to consider alternative designs that exist only as >> Internet Drafts, and the feasibility of the loop check. >> >> I also need to apologize that it has taken far too long for me to >> do this review. There's no good excuse, but I've had some number of >> other documents in the queue this spring, day job requirements, and >> I knew I needed to review this document carefully. The rpl-option >> draft is next on my reading queue, probably reviewed by Monday. >> >> Technical: ======= >> >>> links within a RPL domain SHOULD have a MTU of at least 1280 + 40 >>> (outer IP header) + SRH_MAX_SIZE (+ additional extension headers >>> or options needed within RPL domain) octets. >>> >> >> I thought that 6LOWPAN was an important link layer for the >> application of RPL. Yet, RFC 4944 specifies a MTU of 1280 octets. >> The above requirement seems to be in contradiction with what is >> available on 6LOWPAN. Am I missing some extension of 6LOWPAN that >> changes the MTU, or some other link layer that is expected to be >> used with RPL? If I'm not missing anything, wouldn't this cause a >> problem? It would seem that either you cannot run RPL on 6LOWPAN, >> run 6LOWPAN on non standard MTU values (and we know MTU negotiation >> is difficult), or you have to change the expectations of other >> nodes in the IPv6 Internet about the minimum assured MTU. >> >> Please clarify/resolve/tell me what I am missing. > > Yes, 6LoWPAN is one of the target link layers. I agree that this > statement is problematic with strict adherence to RFC 4944. Note, > however, that there are IEEE 802.15.4 variants (i.e. 802.15.4g) that > support frame lengths up to 2KB. I'm not sure it would be wise to > limit the capabilities of alternative IEEE 802.15.4 link > technologies. > > I would propose to remove the cited statement. It is unnecessary > given that the next revision of this draft will require tunneling. > >>> A common network configuration for a RPL domain is that all >>> nodes within a LLN share a common prefix. The SRH introduces the >>> CmprI, CmprE, and Pad fields to allow compaction of the >>> Address[1..n] vector when all entries share the same prefix as >>> the IPv6 Destination Address field of the packet carrying the >>> SRH. >> >> So all segments are treated based on how many bytes they have in >> common with the destination address. But the destination address >> keeps changing as we go through the intermediate hops. Is it >> necessary to clarify that the comparison/shared prefix is with the >> final destination address, NOT the address that happens to be in >> the destination address field currently? > > The intent really was to utilize the current IPv6 Destination value > since all entries except the last will carry the same CmprI prefix > bytes. Now, I can see there is an issue when we consider the final > entry controlled by CmprE. The intent was that CmprE would only > differ when operating in "transport mode" and the SRH would thus be > removed according to Section 5 of the draft. > >>> In very specific cases, IPv6-in-IPv6 tunneling may be undesirable >>> due to the added cost and complexity required to process and >>> carry a datagram with two IPv6 headers. >>> [I-D.hui-6man-rpl-headers >>> ] >>> describes how to avoid using IPv6-in-IPv6 tunneling in such >>> specific cases and the risks involved. >>> >> >> This sounds like a recommendation to do something in a draft that >> has not been through the working group and approved as the >> something that is a sound practice. Unless the reference is >> normative, I think it is inappropriate to refer to an Internet >> draft in this manner. >> >> What I would recommend is to (1) change the "... SHOULD use >> IPv6-in-IPv6 tunneling ..." statement to a MUST in this draft, (2) >> remove the above text, and (3) make the corresponding changes to >> Section 5. Then we can take hui-6man-rpl-headers through the >> working group and provide a second, more light-weight approach that >> extends what we have RFC-to-be-draft-ietf-6man-rpl-routing-header. >> >> (FWIW, I think the problem begins when one adds the first byte to a >> packet somewhere along the route. It does not not matter so much >> how many bytes one adds, just the SRH or also the IP header. Most >> of the complications on MTUs and so one start at that point. In any >> case, SRHs may not be trivially small either. Assuming 64-bit >> prefix compression an SRH for 4 hops would be 40 bytes.) > > In general, I agree with your concern. However, after re-reading the > draft, do is it necessary to mandate a particular solution (i.e. RFC > 2473)? Instead, how do you feel about the following modified text: > > To deliver a datagram, a router MAY specify a source route to reach > the destination using a SRH. There are two cases that determine how > to include an SRH with a datagram. > > 1. When the source node inserts an SRH, it may do so directly within > the datagram itself. > > 2. When an intermediate node inserts an SRH, it should do so in a > way that does not cause path MTU issues and ensures ICMP errors > caused by inserting the SRH return to the source of the SRH rather > than the original datagram. One such method is IPv6-in-IPv6 > tunneling [RFC 2473]. > >>> If such addresses appear more than once and are separated by at >>> least one address not assigned to that router, the router MUST >>> drop the packet and SHOULD send an ICMP Parameter Problem, Code >>> 0, to the Source Address. >>> >> ... >> >>> else if 2 or more entries in Address[1..n] are assigned to local >>> interface and are separated by at least one address not assigned >>> to local interface { discard the packet } >>> >> >> The text and the code appear to disagree about whether to send an >> ICMP Parameter Problem message. Please align. I assume that an ICMP >> message is needed. > > Agree. > >>> Because this document specifies that SRH is only for use within a >>> RPL domain, such attacks cannot be mounted from outside the RPL >>> domain. As described in Section 5 >>> , >>> RPL Border Routers MUST drop datagrams entering or exiting the >>> RPL domain that contain a SRH in the IPv6 Extension headers. >>> >> >> This is good, and I think the security considerations are >> sufficient. However, I would be happier if the draft also >> recommended that by default, non-RPL routers and firewalls should >> drop packets with SRH. This would help ensure that SRH does not >> accidentally enter any network and expose some vulnerability. The >> practical effect that I'm looking for is, for instance, not having >> my Linux kernel process SRH unless I've configured it to use RPL. > > Agree. > >> Editorial: ====== >> >>> In the above scenario, datagrams traveling from source, S, to >>> destination, D, have the following packet structure: >>> >>> >>> +------+------+------+--------//-+ | IPv6 | IPv6 | IPv6 | Packet >>> | | Src | Dst | SRH | Payload | >>> +------+------+------+--------//-+ >>> >> >> This figure is not as clear as it could be. Are the src and dst >> field referring to the IPv6 header fields? Would this picture be >> better if you showed the IPv6 header explicitly? Please clarify. > > Yes, the src and dst fields are IPv6 header fields. Will update the > figure to be more explicit. > >>> CmprE 4-bit unsigned integer. Number of prefix >>> octets from the segment that are elided. For example, a SRH >>> carrying a full IPv6 address in Addresses[n] sets CmprE to 0. >>> >> >> I understood the definition CmprI, but I do not understand this, at >> least not at the point of the above text. What is "the segment" >> that you are referring to above? SRH carries multiple segments. >> Please clarify. >> >> Little further down it becomes clear that CmprE refers to the >> compression of the last segment. Please make this clear already in >> the above text. > > Correct. Will clarify in the next revision. > >> Comments relating to feedback from others: >> ============================ >> >> The ADs have received a question from Joseph Reddy, who was asking >> if the set of addresses in the SRH should also include the source >> address of the node inserting the SRH. His justification for this >> was the need to be able to send an ICMP error back to this node. Do >> we have an answer? > > When using tunneling, the ICMP error should go back to the source of > the outer IPv6 header. > >> In April, Thomas Narten made some comments on the list and I didn't >> think that the discussion finished with any conclusion. Are his >> concerns (e.g., from his e-mail on April 29th) valid or not valid? >> I would like the working group to conclude this issue one way or >> the other. I refer to his comments regarding the feasibility of the >> loop check in particular. His e-mail is at >> http://www.ietf.org/mail-archive/web/ipv6/current/msg13887.html >> FWIW I agree with Thomas' editorial comment on Section 2 clarity. >> That should be easy to fix. > > > My personal belief is that LLN devices will generally have more > computation capability relative to communication capability, so I'm > not terribly concerned with the processing overhead. That said, I'm > not a fan of the loop check and would prefer less complexity. We > only required such checks to deal with security concerns that have > been raised in the past with RH0. If others feel that the checks are > unnecessary or have alternative suggestions, I'm more than happy to > make the changes. > > Thanks. > > -- Jonathan Hui From joelja@bogus.com Sun Aug 7 10:57:26 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F36C21F86DF for ; Sun, 7 Aug 2011 10:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIvzdvmtzdU5 for ; Sun, 7 Aug 2011 10:57:26 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 040F021F86D7 for ; Sun, 7 Aug 2011 10:57:25 -0700 (PDT) Received: from [192.168.1.118] (adsl-99-173-15-226.dsl.pltn13.sbcglobal.net [99.173.15.226]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p77HvkFi058388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Aug 2011 17:57:48 GMT (envelope-from joelja@bogus.com) From: Joel Jaeggli Content-Type: multipart/alternative; boundary=Apple-Mail-18--574783408 Date: Sun, 7 Aug 2011 10:57:45 -0700 Subject: Questions from the Authors of draft-gashinsky-v6nd-enhance To: ipv6@ietf.org Message-Id: <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 07 Aug 2011 17:57:49 +0000 (UTC) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 17:57:26 -0000 --Apple-Mail-18--574783408 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, This is followup from our discussion in both v6ops and 6man. We got a = lot of useful input, but I would like to ask the mailing list to see if = we can solidify this into a course of action. For reference: ftp://ftp.ietf.org/internet-drafts/draft-gashinsky-v6nd-enhance-00.txt http://tools.ietf.org/agenda/81/slides/6man-9.pdf 1. Is this document (draft-gashinsky-v6nd-enhance) worthwhile? 2. Is there critique of the two proposed 4861 changes? A. 7.3 NDP Protocol Gratuitous NA a. We believe the is the question is whether the = technique would=20 be useful under duress, wether it is potentially = dangerous, if the safeguards are adequate, etc. B. 7.4 ND cache priming and refresh 3. Should we separate the potential mitigations (section 6) and = implementation advice (section 7.1 and 7.2) into a separate document. A. Assumption (validated in v6ops at ietf81) is that v6ops would = be happy to take the mitigation and implementation advice as an = informational document B. Assumption 2 a draft updating 4861 would be a standards track = document. C. Assumption 3, should harmonize with = draft-nordmark-6man-impatient-nud-00 4. Is there anyone who thinks that an update to 4861 to address dos = exposure is unnecessary? A. Just publish the advice and be done with it? Comments on some or all of these questions would help the authors decide = where to go next. Thanks Joel= --Apple-Mail-18--574783408 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii ftp://ftp.ietf.org/internet-drafts/draft-gashinsky-v6nd-enhance-00.t= xt



=
1. Is this document (draft-gashinsky-v6nd-enhance) = worthwhile?

2. Is there critique of the two = proposed 4861 changes?

A. = 7.3  NDP Protocol Gratuitous = NA

= a. We believe the is the question is whether the technique = would 
be useful under duress, = wether it is potentially dangerous,
= if the safeguards are adequate, = etc.

B. 7.4 ND cache priming and refresh

3. Should we separate the = potential mitigations (section 6) and implementation advice (section 7.1 = and 7.2) into a separate document.

A. = Assumption (validated in v6ops at ietf81) is that v6ops would be = happy
=  to take the mitigation and implementation advice as an = informational document

B. = Assumption 2 a draft updating 4861 would be a standards track = document.

C. Assumption 3, should harmonize = with  dr= aft-nordmark-6man-impatient-nud-00

4. Is = there anyone who thinks that an update to 4861 to address dos exposure = is unnecessary?

A. Just publish the advice and be = done with it?

Comments on some or all of these = questions would help the authors decide where to go = next.

Thanks
Joel
= --Apple-Mail-18--574783408-- From ipng@69706e6720323030352d30312d31340a.nosense.org Sun Aug 7 14:57:57 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC59A21F850E for ; Sun, 7 Aug 2011 14:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxY92KJLBF1I for ; Sun, 7 Aug 2011 14:57:57 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id EEAB821F8509 for ; Sun, 7 Aug 2011 14:57:56 -0700 (PDT) Received: from 219-90-209-53.ip.adam.com.au ([219.90.209.53] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QqBMN-000166-Ur; Mon, 08 Aug 2011 07:28:16 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 258733B363; Mon, 8 Aug 2011 07:28:15 +0930 (CST) Date: Mon, 8 Aug 2011 07:28:14 +0930 From: Mark Smith To: Joel Jaeggli Subject: Re: Questions from the Authors of draft-gashinsky-v6nd-enhance Message-ID: <20110808072814.10ca9bec@opy.nosense.org> In-Reply-To: <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com> References: <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.5; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 21:57:57 -0000 Hi Joel, I've been and am in the middle of starting a new job and moving inter-state over the last few weeks, so I haven't been able to spend as much time on this as I'd have liked to, as I'm quite interested in this issue being resolved. I haven't had a chance, and won't over the next few weeks to thoroughly read the draft, hopefully below is useful. I have been working on my own proposal to address this issue by abandoning the state held during the NS/NA transaction, and relying on the traffic originating hosts to retransmit their NS/NA triggering traffic if the stateless NS/NA transaction fails. On Sun, 7 Aug 2011 10:57:45 -0700 Joel Jaeggli wrote: > Greetings, > > This is followup from our discussion in both v6ops and 6man. We got a lot of useful input, but I would like to ask the mailing list to see if we can solidify this into a course of action. > > For reference: > > ftp://ftp.ietf.org/internet-drafts/draft-gashinsky-v6nd-enhance-00.txt > > http://tools.ietf.org/agenda/81/slides/6man-9.pdf > > > 1. Is this document (draft-gashinsky-v6nd-enhance) worthwhile? > Yes > 2. Is there critique of the two proposed 4861 changes? > > A. 7.3 NDP Protocol Gratuitous NA > > a. We believe the is the question is whether the technique would > be useful under duress, wether it is potentially dangerous, > if the safeguards are adequate, etc. > > B. 7.4 ND cache priming and refresh > Haven't had the chance to thoroughly understand them yet. > 3. Should we separate the potential mitigations (section 6) and implementation advice (section 7.1 and 7.2) into a separate document. Yes. > > A. Assumption (validated in v6ops at ietf81) is that v6ops would be happy > to take the mitigation and implementation advice as an informational document > > B. Assumption 2 a draft updating 4861 would be a standards track document. > > C. Assumption 3, should harmonize with draft-nordmark-6man-impatient-nud-00 > > 4. Is there anyone who thinks that an update to 4861 to address dos exposure is unnecessary? > I think this issue is essential to address. The end-users of the Internet, and the services/applications they use, usually reside on LANs, and LANs are vulnerable to this attack. The /127 or similar techniques aren't applicable to LANs or point-to-point links such as SP residential subscriber PPP/PPPoE sessions. A general method to resolve this issue for all links, regardless of their role in the network or their type should be the goal. > A. Just publish the advice and be done with it? > > Comments on some or all of these questions would help the authors decide where to go next. > > Thanks > Joel HTH, Mark. From joelja@bogus.com Sun Aug 7 15:12:29 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DFE21F87BC for ; Sun, 7 Aug 2011 15:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mD+uPFwDwwX for ; Sun, 7 Aug 2011 15:12:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC7F21F86FF for ; Sun, 7 Aug 2011 15:12:28 -0700 (PDT) Received: from [192.168.1.171] (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p77MCgwX071848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 7 Aug 2011 22:12:43 GMT (envelope-from joelja@bogus.com) Subject: Re: Questions from the Authors of draft-gashinsky-v6nd-enhance Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: <20110808072814.10ca9bec@opy.nosense.org> Date: Sun, 7 Aug 2011 15:12:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com> <20110808072814.10ca9bec@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 07 Aug 2011 22:12:43 +0000 (UTC) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Aug 2011 22:12:29 -0000 Thanks! On Aug 7, 2011, at 2:58 PM, Mark Smith wrote: > Hi Joel, >=20 > I've been and am in the middle of starting a new job and moving > inter-state over the last few weeks, so I haven't been able to spend = as > much time on this as I'd have liked to, as I'm quite interested in = this > issue being resolved. I haven't had a chance, and won't over the next > few weeks to thoroughly read the draft, hopefully below is useful. >=20 > I have been working on my own proposal to address this issue by > abandoning the state held during the NS/NA transaction, and relying on > the traffic originating hosts to retransmit their NS/NA triggering > traffic if the stateless NS/NA transaction fails. >=20 > On Sun, 7 Aug 2011 10:57:45 -0700 > Joel Jaeggli wrote: >=20 >> Greetings, >>=20 >> This is followup from our discussion in both v6ops and 6man. We got a = lot of useful input, but I would like to ask the mailing list to see if = we can solidify this into a course of action. >>=20 >> For reference: >>=20 >> = ftp://ftp.ietf.org/internet-drafts/draft-gashinsky-v6nd-enhance-00.txt >>=20 >> http://tools.ietf.org/agenda/81/slides/6man-9.pdf >>=20 >>=20 >> 1. Is this document (draft-gashinsky-v6nd-enhance) worthwhile? >>=20 >=20 > Yes >=20 >> 2. Is there critique of the two proposed 4861 changes? >>=20 >> A. 7.3 NDP Protocol Gratuitous NA >>=20 >> a. We believe the is the question is whether the = technique would=20 >> be useful under duress, wether it is potentially = dangerous, >> if the safeguards are adequate, etc. >>=20 >> B. 7.4 ND cache priming and refresh >>=20 >=20 > Haven't had the chance to thoroughly understand them yet. >=20 >> 3. Should we separate the potential mitigations (section 6) and = implementation advice (section 7.1 and 7.2) into a separate document. >=20 > Yes.=20 >=20 >>=20 >> A. Assumption (validated in v6ops at ietf81) is that v6ops would = be happy >> to take the mitigation and implementation advice as an = informational document >>=20 >> B. Assumption 2 a draft updating 4861 would be a standards track = document. >>=20 >> C. Assumption 3, should harmonize with = draft-nordmark-6man-impatient-nud-00 >>=20 >> 4. Is there anyone who thinks that an update to 4861 to address dos = exposure is unnecessary? >>=20 >=20 > I think this issue is essential to address. The end-users of the > Internet, and the services/applications they use, usually reside on > LANs, and LANs are vulnerable to this attack. The /127 or similar > techniques aren't applicable to LANs or point-to-point links such as = SP > residential subscriber PPP/PPPoE sessions. A general method to resolve > this issue for all links, regardless of their role in the network or > their type should be the goal. >=20 >> A. Just publish the advice and be done with it? >>=20 >> Comments on some or all of these questions would help the authors = decide where to go next. >>=20 >> Thanks >> Joel >=20 > HTH, > Mark. >=20 From pch-b29AA871B@u-1.phicoh.com Mon Aug 8 02:43:50 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345F221F88A5 for ; Mon, 8 Aug 2011 02:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.556 X-Spam-Level: X-Spam-Status: No, score=-4.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BhgGLOZ6bN8 for ; Mon, 8 Aug 2011 02:43:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id A044921F883A for ; Mon, 8 Aug 2011 02:43:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QqMNR-0001i9C; Mon, 8 Aug 2011 11:44:05 +0200 Message-Id: To: Joel Jaeggli Subject: Re: Questions from the Authors of draft-gashinsky-v6nd-enhance From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com In-reply-to: Your message of "Sun, 7 Aug 2011 10:57:45 -0700 ." <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com> Date: Mon, 08 Aug 2011 11:43:50 +0200 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 09:43:50 -0000 In your letter dated Sun, 7 Aug 2011 10:57:45 -0700 you wrote: > B. Assumption 2 a draft updating 4861 would be a standards track = >document. I think it would be best to create a discussion document that describes the various ways that RFC-4861 can be changed to deal with remote attacks on router (and to some extent host) ND. From kerlyn2001@gmail.com Tue Aug 9 14:50:34 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4303D21F8C72 for ; Tue, 9 Aug 2011 14:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.128 X-Spam-Level: X-Spam-Status: No, score=-3.128 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKq6MPASh6au for ; Tue, 9 Aug 2011 14:50:33 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A8A7221F8C6F for ; Tue, 9 Aug 2011 14:50:33 -0700 (PDT) Received: by ywm21 with SMTP id 21so336191ywm.31 for ; Tue, 09 Aug 2011 14:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=fyqnArHRFzv89Zxi4fD4dF0v4Z8uyaJphQpLrlTz9Sw=; b=Z9K7vnNORwsxPfIrmrj3Ofi6PwcLnnsGU/lnQVAHcoH0HebR5lknsTTDL6e0EQlQNH q+q6+qwOysn6CTGAiDbzX6MwqaF+xCfuFtEniX2lQuspTcRrrABiu7qNvxkvbjGvK3Ps 92FJb6P47jLUSjJ3dxxKlIWu2/wFJHosgeQKg= MIME-Version: 1.0 Received: by 10.43.133.202 with SMTP id hz10mr6908701icc.357.1312926663057; Tue, 09 Aug 2011 14:51:03 -0700 (PDT) Received: by 10.43.53.70 with HTTP; Tue, 9 Aug 2011 14:51:03 -0700 (PDT) Date: Tue, 9 Aug 2011 17:51:03 -0400 Message-ID: Subject: RFC 3306 question From: Kerry Lynn To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=20cf307f369c5e22a204aa198f49 X-Mailman-Approved-At: Wed, 10 Aug 2011 00:08:05 -0700 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 21:50:34 -0000 --20cf307f369c5e22a204aa198f49 Content-Type: text/plain; charset=ISO-8859-1 RFC 3306 states: "The scope of the unicast-prefix based multicast address MUST NOT exceed the scope of the unicast prefix embedded in the multicast address." I'd just like to verify my interpretation that site-local multicast addresses MAY be formed from ULA prefixes? If so, should a particular value (e.g. 0x0000) be used as the subnet ID portion of the prefix? Thanks, -K- --20cf307f369c5e22a204aa198f49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable RFC 3306 states:



"The scope of the unicast-pre=
fix based multicast address MUST NOT
exceed the scope of the unicast prefix embedded in the multicast
address."



I'd just like to verify my int=
erpretation that site-local multicast addresses
MAY be formed from ULA prefixes?  If so, should a pa=
rticular value
(e.g. 0x0000) be used as the subnet ID portion of th=
e prefix?



Thanks, -K-


--20cf307f369c5e22a204aa198f49--

From sander@steffann.nl  Wed Aug 10 01:12:41 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969D121F85F7 for ; Wed, 10 Aug 2011 01:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.11
X-Spam-Level: *
X-Spam-Status: No, score=1.11 tagged_above=-999 required=5 tests=[AWL=-1.211,  BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,  HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIE5MrccltZh for ; Wed, 10 Aug 2011 01:12:41 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id CE45921F85F2 for ; Wed, 10 Aug 2011 01:12:40 -0700 (PDT)
Received: from macpro.10ww.steffann.nl (095-097-083-091.static.chello.nl [95.97.83.91]) by mail.sintact.nl (Postfix) with ESMTP id 2E8732046; Wed, 10 Aug 2011 10:13:09 +0200 (CEST)
Subject: Re: RFC 3306 question
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/signed; boundary="Apple-Mail=_33703E54-D17A-43AF-BA01-23764EB4421B"; protocol="application/pkcs7-signature"; micalg=sha1
From: Sander Steffann 
In-Reply-To: 
Date: Wed, 10 Aug 2011 10:13:09 +0200
Message-Id: 
References: 
To: Kerry Lynn 
X-Mailer: Apple Mail (2.1244.3)
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Aug 2011 08:12:41 -0000

--Apple-Mail=_33703E54-D17A-43AF-BA01-23764EB4421B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi,

> I'd just like to verify my interpretation that site-local multicast =
addresses
> MAY be formed from ULA prefixes?

ULA has global scope, so that should be ok.

Met vriendelijke groet,
Sander Steffann



--Apple-Mail=_33703E54-D17A-43AF-BA01-23764EB4421B
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSDCCBUQw
ggMsoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwdjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFwZWxk
b29ybjEVMBMGA1UEChMMU0pNIFN0ZWZmYW5uMR0wGwYDVQQDExRTSk0gU3RlZmZhbm4gUm9vdCBD
QTEdMBsGCSqGSIb3DQEJARYOY2FAc3RlZmZhbm4ubmwwHhcNMTEwODA5MTczMjE2WhcNMTIwODA4
MTczMjE2WjB1MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0g
U3RlZmZhbm4xGDAWBgNVBAMTD1NhbmRlciBTdGVmZmFubjEhMB8GCSqGSIb3DQEJARYSc2FuZGVy
QHN0ZWZmYW5uLm5sMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9b7oVFaA35FKgKq2dZXbh
X1kQl2mgPnaI3OurSyefZ6dyv8JFNM6CAA77kb/Gh5FXVDEJujcRPnE93Lmvmx+82J140WSiTpez
7QY8oBYNDCRP0KksXzwfClZjrG2Afw8S1jH14ymK0HufZ9kEkSWD5WzrxEDSqwnQTyFhsGCrbQID
AQABo4IBYDCCAVwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwKwYJYIZIAYb4QgENBB4W
HFRpbnlDQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMBr5zy4rYkQJ/JeoU3+6lnw
Ebd5MIGoBgNVHSMEgaAwgZ2AFOH79lsAHFEBG+6Vrq192mCYPEg6oXqkeDB2MQswCQYDVQQGEwJO
TDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNK
TSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubIIJALBR3gny
oySYMBkGA1UdEgQSMBCBDmNhQHN0ZWZmYW5uLm5sMB0GA1UdEQQWMBSBEnNhbmRlckBzdGVmZmFu
bi5ubDALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAIOE9ZBvSzDEUrBsMvN3cdkcyywn
mbZhsZhXJrjEsKSEzbDfoyS/gQzX2cN6jwWNMMN34q8nvy3/cMtYxupjL4LfXitPjVSk+C69jaA1
/SNwLpHFAXbW9ikM3deEtJJJcs1t/OvKHa/mGuWq6MHjAOhKqm2ei2L5WLj5sBkFb7o7BeCh6AzL
RWMwYLBpw0xjwxthFsmRC8q4eWFUT+kSMBHSl2EoKBqaYWfxI7oQ/obWAt4OncylGbDKWDQiwW+O
VPFJKe2fHMFp0v/f4+u1NDTUmyjZ+Lxw+4ABZ0pmAjuceN/zrO4IRU/dpHMs38+Wn5glDmDNkSpE
74ropT+BZhMeSpF2fACVtuk/2Wf+0whB1KzUCMZHiCT/UJp5C2pM0kqVE1EjKRAVRTirjf8O2aHr
A5Yn5o80MQKZ9X1UWvUaIMAxbjWQGCX+qD5NmjxptMHPMtj/mVAa1oS1PC87pk5ca9kht1KGGKBX
Pp8wrGIdXRhIGsh4Y6TW6eYVmIgb8WqLqpV5qg4y/irukcxq7Y0DcDv8dRY9Qvr0kJgU1lHV36Vr
kFYJ2+RZFxYKQeS1/KkN33qng79VNsDejVx9jc1XmEgIRkR+3ou6yfBrG6iQrb9DziD4EFZg4sCk
DifH+Am6d7h21ayiHRT+zyqrqIBrgG1e1O+sL8HGKIZN7QioMYICnjCCApoCAQEwezB2MQswCQYD
VQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNV
BAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubAIB
AjAJBgUrDgMCGgUAoIIBeTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMTA4MTAwODEzMTBaMCMGCSqGSIb3DQEJBDEWBBRWW5az/afAryC4LuYb92p6HAc1rDCBigYJ
KwYBBAGCNxAEMX0wezB2MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQK
EwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcN
AQkBFg5jYUBzdGVmZmFubi5ubAIBAjCBjAYLKoZIhvcNAQkQAgsxfaB7MHYxCzAJBgNVBAYTAk5M
MRIwEAYDVQQHEwlBcGVsZG9vcm4xFTATBgNVBAoTDFNKTSBTdGVmZmFubjEdMBsGA1UEAxMUU0pN
IFN0ZWZmYW5uIFJvb3QgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQHN0ZWZmYW5uLm5sAgECMA0GCSqG
SIb3DQEBAQUABIGABMonDHvsW0pvhdPRwxfM2T1LFbRUH2j98x5x+UTfQpjJ5/ZiyfcGp05+lSt+
RlEus4w1F6b21opcaEEhJWb7XmHkFzb/+pXC4IqGNhcs3fw2UECseTn2ElJkPK24vYZ5NmBf9t6v
jOBGQgJaXDIipRjmvkk4fHC+DgR+c1ZiqmwAAAAAAAA=

--Apple-Mail=_33703E54-D17A-43AF-BA01-23764EB4421B--

From brian@innovationslab.net  Wed Aug 10 06:53:45 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CED321F8A1A for ; Wed, 10 Aug 2011 06:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfllefpnp1jo for ; Wed, 10 Aug 2011 06:53:45 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 26B6821F89A7 for ; Wed, 10 Aug 2011 06:53:45 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C94FE88214 for ; Wed, 10 Aug 2011 06:54:16 -0700 (PDT)
Received: from clemson.local (unknown [75.94.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 04B91130002 for ; Wed, 10 Aug 2011 06:54:15 -0700 (PDT)
Message-ID: <4E428D83.4060501@innovationslab.net>
Date: Wed, 10 Aug 2011 09:54:11 -0400
From: Brian Haberman 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: RFC 3306 question
References: 
In-Reply-To: 
X-Enigmail-Version: 1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 Aug 2011 13:53:45 -0000

On 8/9/11 5:51 PM, Kerry Lynn wrote:
> RFC 3306 states:
> 
> 
> "The scope of the unicast-prefix based multicast address MUST NOT
> exceed the scope of the unicast prefix embedded in the multicast
> address."
> 
> 
> I'd just like to verify my interpretation that site-local multicast addresses
> 
> MAY be formed from ULA prefixes?  If so, should a particular value

Yes, there is no issue with using a ULA prefix to form a unicast-prefix
based multicast address with site-local scope.

> 
> (e.g. 0x0000) be used as the subnet ID portion of the prefix?
> 

What you use in the subnet portion of the ULA is really up to your use case.

Regards,
Brian


From brian.e.carpenter@gmail.com  Thu Aug 11 15:05:51 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642FF21F8AF1 for ; Thu, 11 Aug 2011 15:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.601
X-Spam-Level: 
X-Spam-Status: No, score=-103.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbLRaXm1lDKQ for ; Thu, 11 Aug 2011 15:05:51 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D222621F8AF0 for ; Thu, 11 Aug 2011 15:05:50 -0700 (PDT)
Received: by vxi29 with SMTP id 29so2484487vxi.31 for ; Thu, 11 Aug 2011 15:06:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EOFZ1w34fIQ4qgIuZomPyc9e44R482XhzPqpYLarJS8=; b=CJSeMhzLQ/6nJ3o9sCQ1F0Eb+uQCCDTIAgyGIttwU71JMenHhMWUgCiK4w8avru6RE uZZTbj0kfrMPk/k5Sccoy/SCN18UeShMKitXXvPwUZrpdBraUL4N803QJ0/9tq972GBY B1DxbzouLRXwOVScdKjoXugVCg2M71gmZio5M=
Received: by 10.52.23.225 with SMTP id p1mr158484vdf.186.1313100385665; Thu, 11 Aug 2011 15:06:25 -0700 (PDT)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id pm1sm1065560vcb.33.2011.08.11.15.06.23 (version=SSLv3 cipher=OTHER); Thu, 11 Aug 2011 15:06:25 -0700 (PDT)
Message-ID: <4E445261.3040506@gmail.com>
Date: Fri, 12 Aug 2011 10:06:25 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: 6man 
Subject: A6 record status
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Tim Chown 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2011 22:05:51 -0000

Hi,

What do 6man people think about moving RFC 2874 (the A6 record)
from Experimental to Historic status?

It's pretty clear that it doesn't have any real value, and
it can still create confusion for newcomers.

IMHO this doesn't need a draft; the IESG could just do it.

Regards
   Brian Carpenter

From sander@steffann.nl  Thu Aug 11 15:55:20 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9980F11E8093 for ; Thu, 11 Aug 2011 15:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.262
X-Spam-Level: *
X-Spam-Status: No, score=1.262 tagged_above=-999 required=5 tests=[AWL=-1.059,  BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,  HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HOST_EQ_STATIC=1.172]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOw9klJsdYN9 for ; Thu, 11 Aug 2011 15:55:20 -0700 (PDT)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id E3E1C11E8092 for ; Thu, 11 Aug 2011 15:55:19 -0700 (PDT)
Received: from macpro.10ww.steffann.nl (095-097-083-091.static.chello.nl [95.97.83.91]) by mail.sintact.nl (Postfix) with ESMTP id D52F0200A; Fri, 12 Aug 2011 00:55:53 +0200 (CEST)
Subject: Re: A6 record status
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/signed; boundary="Apple-Mail=_F7FE9E80-E941-4585-A5A0-8711B801855B"; protocol="application/pkcs7-signature"; micalg=sha1
From: Sander Steffann 
In-Reply-To: <4E445261.3040506@gmail.com>
Date: Fri, 12 Aug 2011 00:55:53 +0200
Message-Id: 
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1244.3)
Cc: 6man 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2011 22:55:20 -0000

--Apple-Mail=_F7FE9E80-E941-4585-A5A0-8711B801855B
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Hi Brian,

> What do 6man people think about moving RFC 2874 (the A6 record)
> from Experimental to Historic status?


I really thought that it already was Historic :-)  No objection at all!

Thanks,
Sander



--Apple-Mail=_F7FE9E80-E941-4585-A5A0-8711B801855B
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFSDCCBUQw
ggMsoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwdjELMAkGA1UEBhMCTkwxEjAQBgNVBAcTCUFwZWxk
b29ybjEVMBMGA1UEChMMU0pNIFN0ZWZmYW5uMR0wGwYDVQQDExRTSk0gU3RlZmZhbm4gUm9vdCBD
QTEdMBsGCSqGSIb3DQEJARYOY2FAc3RlZmZhbm4ubmwwHhcNMTEwODA5MTczMjE2WhcNMTIwODA4
MTczMjE2WjB1MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0g
U3RlZmZhbm4xGDAWBgNVBAMTD1NhbmRlciBTdGVmZmFubjEhMB8GCSqGSIb3DQEJARYSc2FuZGVy
QHN0ZWZmYW5uLm5sMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9b7oVFaA35FKgKq2dZXbh
X1kQl2mgPnaI3OurSyefZ6dyv8JFNM6CAA77kb/Gh5FXVDEJujcRPnE93Lmvmx+82J140WSiTpez
7QY8oBYNDCRP0KksXzwfClZjrG2Afw8S1jH14ymK0HufZ9kEkSWD5WzrxEDSqwnQTyFhsGCrbQID
AQABo4IBYDCCAVwwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBLAwKwYJYIZIAYb4QgENBB4W
HFRpbnlDQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMBr5zy4rYkQJ/JeoU3+6lnw
Ebd5MIGoBgNVHSMEgaAwgZ2AFOH79lsAHFEBG+6Vrq192mCYPEg6oXqkeDB2MQswCQYDVQQGEwJO
TDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNK
TSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubIIJALBR3gny
oySYMBkGA1UdEgQSMBCBDmNhQHN0ZWZmYW5uLm5sMB0GA1UdEQQWMBSBEnNhbmRlckBzdGVmZmFu
bi5ubDALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBAIOE9ZBvSzDEUrBsMvN3cdkcyywn
mbZhsZhXJrjEsKSEzbDfoyS/gQzX2cN6jwWNMMN34q8nvy3/cMtYxupjL4LfXitPjVSk+C69jaA1
/SNwLpHFAXbW9ikM3deEtJJJcs1t/OvKHa/mGuWq6MHjAOhKqm2ei2L5WLj5sBkFb7o7BeCh6AzL
RWMwYLBpw0xjwxthFsmRC8q4eWFUT+kSMBHSl2EoKBqaYWfxI7oQ/obWAt4OncylGbDKWDQiwW+O
VPFJKe2fHMFp0v/f4+u1NDTUmyjZ+Lxw+4ABZ0pmAjuceN/zrO4IRU/dpHMs38+Wn5glDmDNkSpE
74ropT+BZhMeSpF2fACVtuk/2Wf+0whB1KzUCMZHiCT/UJp5C2pM0kqVE1EjKRAVRTirjf8O2aHr
A5Yn5o80MQKZ9X1UWvUaIMAxbjWQGCX+qD5NmjxptMHPMtj/mVAa1oS1PC87pk5ca9kht1KGGKBX
Pp8wrGIdXRhIGsh4Y6TW6eYVmIgb8WqLqpV5qg4y/irukcxq7Y0DcDv8dRY9Qvr0kJgU1lHV36Vr
kFYJ2+RZFxYKQeS1/KkN33qng79VNsDejVx9jc1XmEgIRkR+3ou6yfBrG6iQrb9DziD4EFZg4sCk
DifH+Am6d7h21ayiHRT+zyqrqIBrgG1e1O+sL8HGKIZN7QioMYICnjCCApoCAQEwezB2MQswCQYD
VQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQKEwxTSk0gU3RlZmZhbm4xHTAbBgNV
BAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcNAQkBFg5jYUBzdGVmZmFubi5ubAIB
AjAJBgUrDgMCGgUAoIIBeTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xMTA4MTEyMjU1NTNaMCMGCSqGSIb3DQEJBDEWBBQxHeLN+4xDha5uNegv09/CAkrnwzCBigYJ
KwYBBAGCNxAEMX0wezB2MQswCQYDVQQGEwJOTDESMBAGA1UEBxMJQXBlbGRvb3JuMRUwEwYDVQQK
EwxTSk0gU3RlZmZhbm4xHTAbBgNVBAMTFFNKTSBTdGVmZmFubiBSb290IENBMR0wGwYJKoZIhvcN
AQkBFg5jYUBzdGVmZmFubi5ubAIBAjCBjAYLKoZIhvcNAQkQAgsxfaB7MHYxCzAJBgNVBAYTAk5M
MRIwEAYDVQQHEwlBcGVsZG9vcm4xFTATBgNVBAoTDFNKTSBTdGVmZmFubjEdMBsGA1UEAxMUU0pN
IFN0ZWZmYW5uIFJvb3QgQ0ExHTAbBgkqhkiG9w0BCQEWDmNhQHN0ZWZmYW5uLm5sAgECMA0GCSqG
SIb3DQEBAQUABIGAMI3n3/PDZbC+Ws1tKcrg6woN8Cu6Q1zYFu5GdarKDJLm6dLK1Fwkj4a/aVWI
ofi9GYRSvgRulq6QsDSkEUR30n6IS7DcUIytTLYq00Nliuk4q/sie8B6b5R4DNQrvJuQ1uy8Rl9K
ma0w8QEae1GND5DiMyjoUJKEaig/17urf8sAAAAAAAA=

--Apple-Mail=_F7FE9E80-E941-4585-A5A0-8711B801855B--

From Tina.Tsou.Zouting@huawei.com  Thu Aug 11 15:12:22 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1EB21F86DF for ; Thu, 11 Aug 2011 15:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.942
X-Spam-Level: 
X-Spam-Status: No, score=-4.942 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZI74BVtHbY5 for ; Thu, 11 Aug 2011 15:12:22 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 952B521F86CA for ; Thu, 11 Aug 2011 15:12:21 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPS00IWZB1HLJ@szxga03-in.huawei.com> for ipv6@ietf.org; Fri, 12 Aug 2011 06:12:53 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPS00HFCB1HIO@szxga03-in.huawei.com> for ipv6@ietf.org; Fri, 12 Aug 2011 06:12:53 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119])	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC86720; Fri, 12 Aug 2011 06:12:49 +0800 (CST)
Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 12 Aug 2011 06:12:43 +0800
Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.99]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Fri, 12 Aug 2011 06:12:47 +0800
Date: Thu, 11 Aug 2011 22:12:46 +0000
From: Tina TSOU 
Subject: RE: A6 record status
In-reply-to: <4E445261.3040506@gmail.com>
X-Originating-IP: [10.193.34.126]
To: Brian E Carpenter , 6man 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Accept-Language: en-US, zh-CN
Thread-topic: A6 record status
Thread-index: AQHMWHMnXCqK8Xa3QkOsr0cAvhp5q5UYNm6A
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com>
X-Mailman-Approved-At: Thu, 11 Aug 2011 16:15:18 -0700
Cc: Tim Chown 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2011 22:12:22 -0000

Brian,
I'm with you. I don't use A6 record in any case.


Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
Sent: Thursday, August 11, 2011 3:06 PM
To: 6man
Cc: Tim Chown
Subject: A6 record status

Hi,

What do 6man people think about moving RFC 2874 (the A6 record)
from Experimental to Historic status?

It's pretty clear that it doesn't have any real value, and
it can still create confusion for newcomers.

IMHO this doesn't need a draft; the IESG could just do it.

Regards
   Brian Carpenter
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

From huitema@microsoft.com  Thu Aug 11 16:17:48 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C466921F8B08 for ; Thu, 11 Aug 2011 16:17:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.668
X-Spam-Level: 
X-Spam-Status: No, score=-10.668 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfIKdlWJqWTX for ; Thu, 11 Aug 2011 16:17:48 -0700 (PDT)
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 47E2B21F8AF1 for ; Thu, 11 Aug 2011 16:17:48 -0700 (PDT)
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 11 Aug 2011 16:18:23 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Aug 2011 16:18:23 -0700
Received: from TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.26]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0323.007; Thu, 11 Aug 2011 16:18:23 -0700
From: Christian Huitema 
To: Tina TSOU , Brian E Carpenter , 6man 
Subject: RE: A6 record status
Thread-Topic: A6 record status
Thread-Index: AQHMWHL4ehZmQwvXRECjtJroV+4PpZUYrAsA//+czoA=
Date: Thu, 11 Aug 2011 23:18:22 +0000
Message-ID: <22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.90]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Tim Chown 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2011 23:17:48 -0000

It looked like a great idea at the time, but the time has passed, and histo=
ric is clearly appropriate.=20

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Tin=
a TSOU
Sent: Thursday, August 11, 2011 3:13 PM
To: Brian E Carpenter; 6man
Cc: Tim Chown
Subject: RE: A6 record status

Brian,
I'm with you. I don't use A6 record in any case.


Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bri=
an E Carpenter
Sent: Thursday, August 11, 2011 3:06 PM
To: 6man
Cc: Tim Chown
Subject: A6 record status

Hi,

What do 6man people think about moving RFC 2874 (the A6 record) from Experi=
mental to Historic status?

It's pretty clear that it doesn't have any real value, and it can still cre=
ate confusion for newcomers.

IMHO this doesn't need a draft; the IESG could just do it.

Regards
   Brian Carpenter
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From marka@isc.org  Thu Aug 11 16:47:57 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B1C11E80AF for ; Thu, 11 Aug 2011 16:47:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.603
X-Spam-Level: 
X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cohl0k0uxKJE for ; Thu, 11 Aug 2011 16:47:57 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 0025611E80AE for ; Thu, 11 Aug 2011 16:47:56 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id E8F845F98BF; Thu, 11 Aug 2011 23:47:50 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E6E3C216C7B; Thu, 11 Aug 2011 23:47:48 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id C922612BD870; Fri, 12 Aug 2011 09:47:42 +1000 (EST)
To: Christian Huitema 
From: Mark Andrews 
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com>  <22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
Subject: Re: A6 record status
In-reply-to: Your message of "Thu, 11 Aug 2011 23:18:22 GMT." <22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>
Date: Fri, 12 Aug 2011 09:47:42 +1000
Message-Id: <20110811234742.C922612BD870@drugs.dv.isc.org>
Cc: Tim Chown , 6man , Brian E Carpenter , Tina TSOU 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 Aug 2011 23:47:57 -0000

I think it is make work and won't change the amount of confusion.
In addition A6 allows compresssion of the domain name in the rdata
so it can't be treated as unknown (i.e. a opaque blob) by nameservers.

If one wants to do something about IPv6 addresses in the DNS add
support for scoped addresses.  Link-local could then be useful.

Mark

In message <22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.win
deploy.ntdev.microsoft.com>, Christian Huitema writes:
> It looked like a great idea at the time, but the time has passed, and historic
>  is clearly appropriate. 
> 
> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Tina T
> SOU
> Sent: Thursday, August 11, 2011 3:13 PM
> To: Brian E Carpenter; 6man
> Cc: Tim Chown
> Subject: RE: A6 record status
> 
> Brian,
> I'm with you. I don't use A6 record in any case.
> 
> 
> Best Regards,
> Tina TSOU
> http://tinatsou.weebly.com/contact.html
> 
> 
> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian 
> E Carpenter
> Sent: Thursday, August 11, 2011 3:06 PM
> To: 6man
> Cc: Tim Chown
> Subject: A6 record status
> 
> Hi,
> 
> What do 6man people think about moving RFC 2874 (the A6 record) from Experimen
> tal to Historic status?
> 
> It's pretty clear that it doesn't have any real value, and it can still create
>  confusion for newcomers.
> 
> IMHO this doesn't need a draft; the IESG could just do it.
> 
> Regards
>    Brian Carpenter
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From jiangsheng@huawei.com  Thu Aug 11 17:56:48 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C7621F8B15 for ; Thu, 11 Aug 2011 17:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.211
X-Spam-Level: 
X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.388,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88cM4B7ramDP for ; Thu, 11 Aug 2011 17:56:47 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 66E6021F8B14 for ; Thu, 11 Aug 2011 17:56:47 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPS008Y7INHAX@szxga05-in.huawei.com> for ipv6@ietf.org; Fri, 12 Aug 2011 08:57:17 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPS00AX3ING7O@szxga05-in.huawei.com> for ipv6@ietf.org; Fri, 12 Aug 2011 08:57:17 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119])	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC89820; Fri, 12 Aug 2011 08:57:16 +0800 (CST)
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 12 Aug 2011 08:57:10 +0800
Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Fri, 12 Aug 2011 08:57:15 +0800
Date: Fri, 12 Aug 2011 00:57:13 +0000
From: Jiangsheng 
Subject: RE: A6 record status
In-reply-to: <4E445261.3040506@gmail.com>
X-Originating-IP: [10.110.98.152]
To: Brian E Carpenter , 6man 
Message-id: <5D36713D8A4E7348A7E10DF7437A4B920122BB38@SZXEML506-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: en-GB, zh-CN, en-US
Thread-topic: A6 record status
Thread-index: AQHMWHLrmIDSjNWJLka/OSinMjVthZUYY04w
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com>
Cc: Tim Chown 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 00:56:48 -0000

+1

When we did 6renum current practise analysis, we found A6 record is helpful in renumbering cases. However, we then found it has many issues, which has been documented in RFC 3363 and RFC 3364. If A6 stays experimental status, it is really misleading. We should avoid this confusion by moving it to Historic.

Sheng 

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Friday, August 12, 2011 6:06 AM
> To: 6man
> Cc: Jiangsheng; Tim Chown
> Subject: A6 record status
> 
> Hi,
> 
> What do 6man people think about moving RFC 2874 (the A6 record)
> from Experimental to Historic status?
> 
> It's pretty clear that it doesn't have any real value, and
> it can still create confusion for newcomers.
> 
> IMHO this doesn't need a draft; the IESG could just do it.
> 
> Regards
>    Brian Carpenter

From brian.e.carpenter@gmail.com  Thu Aug 11 18:05:40 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1615911E80C0 for ; Thu, 11 Aug 2011 18:05:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.601
X-Spam-Level: 
X-Spam-Status: No, score=-103.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idFLEv88F+AN for ; Thu, 11 Aug 2011 18:05:39 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A20E11E80A9 for ; Thu, 11 Aug 2011 18:05:39 -0700 (PDT)
Received: by yxp4 with SMTP id 4so1984787yxp.31 for ; Thu, 11 Aug 2011 18:06:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XD7y3S+74G7ih5eLW2xpDotFMow0/Wkt+rbp+LlkmRc=; b=BLGodA3swB5yinrNmg8p2yipzVP/D9Iwx+bqukd3EFElsyXNT/KimKcqcuHHHgWGhl LI7fetILQz1oCXXdpG38fyCVlsbKcGq3ByZRxJ7K+Fs/nzCSSGUv+Vwj7Ha+6Eh/2S3Q yzwxuMxUCo6oU6IsvWJ6calMFzqHVaKmQoSU4=
Received: by 10.150.158.17 with SMTP id g17mr1274032ybe.378.1313111174514; Thu, 11 Aug 2011 18:06:14 -0700 (PDT)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id y18sm1458556ybn.6.2011.08.11.18.06.10 (version=SSLv3 cipher=OTHER); Thu, 11 Aug 2011 18:06:13 -0700 (PDT)
Message-ID: <4E447C7E.30202@gmail.com>
Date: Fri, 12 Aug 2011 13:06:06 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mark Andrews 
Subject: Re: A6 record status
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com>  <22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <20110811234742.C922612BD870@drugs.dv.isc.org>
In-Reply-To: <20110811234742.C922612BD870@drugs.dv.isc.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Christian Huitema , Tim Chown , 6man , Tina TSOU 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 01:05:40 -0000

On 2011-08-12 11:47, Mark Andrews wrote:
> I think it is make work 

That's why I am only suggesting an IESG decision, not a draft
and an RFC.

> and won't change the amount of confusion.
> In addition A6 allows compresssion of the domain name in the rdata
> so it can't be treated as unknown (i.e. a opaque blob) by nameservers.

If it's historic, servers shouldn't even contain any A6 records,
surely?

> If one wants to do something about IPv6 addresses in the DNS add
> support for scoped addresses.  Link-local could then be useful.

Different topic, and I suspect much more complex.

   Brian

> Mark
> 
> In message <22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.win
> deploy.ntdev.microsoft.com>, Christian Huitema writes:
>> It looked like a great idea at the time, but the time has passed, and historic
>>  is clearly appropriate. 
>>
>> -----Original Message-----
>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Tina T
>> SOU
>> Sent: Thursday, August 11, 2011 3:13 PM
>> To: Brian E Carpenter; 6man
>> Cc: Tim Chown
>> Subject: RE: A6 record status
>>
>> Brian,
>> I'm with you. I don't use A6 record in any case.
>>
>>
>> Best Regards,
>> Tina TSOU
>> http://tinatsou.weebly.com/contact.html
>>
>>
>> -----Original Message-----
>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian 
>> E Carpenter
>> Sent: Thursday, August 11, 2011 3:06 PM
>> To: 6man
>> Cc: Tim Chown
>> Subject: A6 record status
>>
>> Hi,
>>
>> What do 6man people think about moving RFC 2874 (the A6 record) from Experimen
>> tal to Historic status?
>>
>> It's pretty clear that it doesn't have any real value, and it can still create
>>  confusion for newcomers.
>>
>> IMHO this doesn't need a draft; the IESG could just do it.
>>
>> Regards
>>    Brian Carpenter
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------

From marka@isc.org  Thu Aug 11 21:56:34 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15D921F86AD for ; Thu, 11 Aug 2011 21:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svBvTpIZnVNw for ; Thu, 11 Aug 2011 21:56:34 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2B821F8698 for ; Thu, 11 Aug 2011 21:56:34 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 245EA5F98D3; Fri, 12 Aug 2011 04:56:52 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 45EED216C7B; Fri, 12 Aug 2011 04:56:50 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 39BF212BFBCF; Fri, 12 Aug 2011 14:56:44 +1000 (EST)
To: Brian E Carpenter 
From: Mark Andrews 
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com>  <22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <20110811234742.C922612BD870@drugs.dv.isc.org> <4E447C7E.30202@gmail.com>
Subject: Re: A6 record status
In-reply-to: Your message of "Fri, 12 Aug 2011 13:06:06 +1200." <4E447C7E.30202@gmail.com>
Date: Fri, 12 Aug 2011 14:56:44 +1000
Message-Id: <20110812045644.39BF212BFBCF@drugs.dv.isc.org>
Cc: Christian Huitema , Tim Chown , 6man , Tina TSOU 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 04:56:34 -0000

In message <4E447C7E.30202@gmail.com>, Brian E Carpenter writes:
> On 2011-08-12 11:47, Mark Andrews wrote:
> > I think it is make work 
> 
> That's why I am only suggesting an IESG decision, not a draft
> and an RFC.
> 
> > and won't change the amount of confusion.
> > In addition A6 allows compresssion of the domain name in the rdata
> > so it can't be treated as unknown (i.e. a opaque blob) by nameservers.
> 
> If it's historic, servers shouldn't even contain any A6 records,
> surely?

Making something historic doesn't remove the old software or the
old records.  Removing knowledge of A6 from recursive server will
result in garbage A6 records being delivered to old clients that
are A6 aware.  A6 aware clients still work as they ask for both
AAAA and A6 records.

One needs a phase out plan if you want to remove A6 support and it
is likely to need to be decades long given how long people run old
nameservers for.

> > If one wants to do something about IPv6 addresses in the DNS add
> > support for scoped addresses.  Link-local could then be useful.
> 
> Different topic, and I suspect much more complex.
>
>    Brian
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From jiangsheng@huawei.com  Thu Aug 11 23:32:02 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC1111E807F for ; Thu, 11 Aug 2011 23:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.222
X-Spam-Level: 
X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.377,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZ-62dMCl86M for ; Thu, 11 Aug 2011 23:32:02 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D503121F84D7 for ; Thu, 11 Aug 2011 23:32:01 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPS00A5MX9D06@szxga05-in.huawei.com> for ipv6@ietf.org; Fri, 12 Aug 2011 14:12:49 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPS00F5UX9BCS@szxga05-in.huawei.com> for ipv6@ietf.org; Fri, 12 Aug 2011 14:12:49 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119])	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADD01182; Fri, 12 Aug 2011 14:12:47 +0800 (CST)
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 12 Aug 2011 14:12:41 +0800
Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Fri, 12 Aug 2011 14:12:42 +0800
Date: Fri, 12 Aug 2011 06:12:40 +0000
From: Sheng Jiang 
Subject: RE: A6 record status
In-reply-to: <20110812045644.39BF212BFBCF@drugs.dv.isc.org>
X-Originating-IP: [10.110.98.152]
To: Mark Andrews , Brian E Carpenter 
Message-id: <5D36713D8A4E7348A7E10DF7437A4B920122BD2C@SZXEML506-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: en-GB, zh-CN, en-US
Thread-topic: A6 record status
Thread-index: AQHMWKw7mIDSjNWJLka/OSinMjVthZUYuw+w
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com>  <22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <20110811234742.C922612BD870@drugs.dv.isc.org> <4E447C7E.30202@gmail.com> <20110812045644.39BF212BFBCF@drugs.dv.isc.org>
Cc: Christian Huitema , Tim Chown , 6man , Tina TSOU 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 06:32:02 -0000

> In message <4E447C7E.30202@gmail.com>, Brian E Carpenter writes:
> > On 2011-08-12 11:47, Mark Andrews wrote:
> > > I think it is make work
> >
> > That's why I am only suggesting an IESG decision, not a draft
> > and an RFC.
> >
> > > and won't change the amount of confusion.
> > > In addition A6 allows compresssion of the domain name in the rdata
> > > so it can't be treated as unknown (i.e. a opaque blob) by
> nameservers.
> >
> > If it's historic, servers shouldn't even contain any A6 records,
> > surely?
> 
> Making something historic doesn't remove the old software or the
> old records.  Removing knowledge of A6 from recursive server will
> result in garbage A6 records being delivered to old clients that
> are A6 aware.  A6 aware clients still work as they ask for both
> AAAA and A6 records.

Yes, your statement are right. However, the case of A6 is there are few current A6 software or records. As far as I know, there are no commercial A6 supports in the current global DNS system. A6 only existed in some experimental system, like 6net. So, what we are worried here is not these existing A6. By moving A6 into historic, we are preventing any NEW A6 implementation or deployment.

Sheng
 
> One needs a phase out plan if you want to remove A6 support and it
> is likely to need to be decades long given how long people run old
> nameservers for.
> 
> > > If one wants to do something about IPv6 addresses in the DNS add
> > > support for scoped addresses.  Link-local could then be useful.
> >
> > Different topic, and I suspect much more complex.
> >
> >    Brian
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

From rogerj@gmail.com  Thu Aug 11 23:39:36 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E82B11E8088 for ; Thu, 11 Aug 2011 23:39:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kD-hMC+jJJMz for ; Thu, 11 Aug 2011 23:39:35 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40CC411E808C for ; Thu, 11 Aug 2011 23:39:09 -0700 (PDT)
Received: by bkar4 with SMTP id r4so1773648bka.31 for ; Thu, 11 Aug 2011 23:39:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=glFmYlszQsEQY1SnnXUE9YzVXNZG6DBYx3AA8JtxKOs=; b=Q/b79XIuofNL+eNqbTboojnO124SK5MRps/E+W4mnDLpc8RLHtzw0gpxde27yDFsE7 ilEkfYzwtsknaDTkK7sRUDKoISzCzBQzRQt4s/Vx8iXoRazipXh9lzub2FcxvoAqcGle Q5yVybXumy4rCz4CGgjeCs0TjXn7j858sErO0=
MIME-Version: 1.0
Received: by 10.204.48.208 with SMTP id s16mr184735bkf.167.1313131180707; Thu, 11 Aug 2011 23:39:40 -0700 (PDT)
Received: by 10.204.179.69 with HTTP; Thu, 11 Aug 2011 23:39:40 -0700 (PDT)
In-Reply-To: <4E445261.3040506@gmail.com>
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com>
Date: Fri, 12 Aug 2011 08:39:40 +0200
Message-ID: 
Subject: Re: A6 record status
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
To: Brian E Carpenter 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Tim Chown , 6man 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 06:39:36 -0000

On Fri, Aug 12, 2011 at 12:06 AM, Brian E Carpenter
 wrote:
> Hi,
>
> What do 6man people think about moving RFC 2874 (the A6 record)
> from Experimental to Historic status?
>
> It's pretty clear that it doesn't have any real value, and
> it can still create confusion for newcomers.

uh, thought (as others have mention) that it was gone years and years
ago. Please move it on.



--=20

Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 |
rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key!
http://www.jorgensen.no=A0=A0 | roger@jorgensen.no

From marka@isc.org  Fri Aug 12 00:11:44 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B230D21F8686 for ; Fri, 12 Aug 2011 00:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40kxUn15FNA9 for ; Fri, 12 Aug 2011 00:11:43 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id C0F2D21F867A for ; Fri, 12 Aug 2011 00:11:42 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 85C865F98F1; Fri, 12 Aug 2011 07:11:49 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 99A0A216C80; Fri, 12 Aug 2011 07:11:42 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0B6CD12C1D5B; Fri, 12 Aug 2011 17:11:31 +1000 (EST)
To: Sheng Jiang 
From: Mark Andrews 
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com>  <22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <20110811234742.C922612BD870@drugs.dv.isc.org> <4E447C7E.30202@gmail.com> <20110812045644.39BF212BFBCF@drugs.dv.isc.or g> <5D36713D8A4E7348A7E10DF7437A4B920122BD2C@SZXEML506-MBS.china.huawei.com>
Subject: Re: A6 record status
In-reply-to: Your message of "Fri, 12 Aug 2011 06:12:40 GMT." <5D36713D8A4E7348A7E10DF7437A4B920122BD2C@SZXEML506-MBS.china.huawei.com>
Date: Fri, 12 Aug 2011 17:11:31 +1000
Message-Id: <20110812071132.0B6CD12C1D5B@drugs.dv.isc.org>
Cc: Christian Huitema , Tim Chown , 6man , Brian E Carpenter , Tina TSOU 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 07:11:44 -0000

In message <5D36713D8A4E7348A7E10DF7437A4B920122BD2C@SZXEML506-MBS.china.huawei
.com>, Sheng Jiang writes:
> > In message <4E447C7E.30202@gmail.com>, Brian E Carpenter writes:
> > > On 2011-08-12 11:47, Mark Andrews wrote:
> > > > I think it is make work
> > >
> > > That's why I am only suggesting an IESG decision, not a draft
> > > and an RFC.
> > >
> > > > and won't change the amount of confusion.
> > > > In addition A6 allows compresssion of the domain name in the rdata
> > > > so it can't be treated as unknown (i.e. a opaque blob) by
> > nameservers.
> > >
> > > If it's historic, servers shouldn't even contain any A6 records,
> > > surely?
> > 
> > Making something historic doesn't remove the old software or the
> > old records.  Removing knowledge of A6 from recursive server will
> > result in garbage A6 records being delivered to old clients that
> > are A6 aware.  A6 aware clients still work as they ask for both
> > AAAA and A6 records.
> 
> Yes, your statement are right. However, the case of A6 is there are few curre
> nt A6 software or records. As far as I know, there are no commercial A6 suppo
> rts in the current global DNS system. A6 only existed in some experimental sy
> stem, like 6net. So, what we are worried here is not these existing A6. By mo
> ving A6 into historic, we are preventing any NEW A6 implementation or deploym
> ent.
> 
> Sheng

The root servers are getting 100's of A6 q/s (~20:1 AAAA:A6
).  There is
still a very large base of A6 using software out there regardless
of whether they are getting NODATA responses or not.

I don't know what percentage of responses are NODATA and what have
actual A6 records.  I do think we need to know answers to these sorts
of questions.

Mark

> > One needs a phase out plan if you want to remove A6 support and it
> > is likely to need to be decades long given how long people run old
> > nameservers for.
> > 
> > > > If one wants to do something about IPv6 addresses in the DNS add
> > > > support for scoped addresses.  Link-local could then be useful.
> > >
> > > Different topic, and I suspect much more complex.
> > >
> > >    Brian
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From sm@resistor.net  Fri Aug 12 00:38:39 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E831B21F84F3 for ; Fri, 12 Aug 2011 00:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.582
X-Spam-Level: 
X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9IjexJml0wL for ; Fri, 12 Aug 2011 00:38:36 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 351BA21F852C for ; Fri, 12 Aug 2011 00:38:35 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p7C7cjQI006098; Fri, 12 Aug 2011 00:38:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1313134743; bh=aT3kG2rkrtX3c4byD+a5sDGPLVCditpV+buPszKRDA8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=VbOOSZMsycWOJoynTx/xt0opYEF1MN64Gs5SsGhn7Om4eGrQXgnlBBhtpm403oov6 rlPLlNAXqDKSfFFcx8n4AqyepOZAvNRr/sfDprIzYrHbeJAoTCHGVz1z+OCxoXA+tC +x6CBJN5zZXoKpAu59vJdEfOiFLjscMtrJAEjc00=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1313134743; bh=aT3kG2rkrtX3c4byD+a5sDGPLVCditpV+buPszKRDA8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=4GmVCyCo+amsp0gFTPsc/gXQEOJ82B6NnL0nxyZbgRW25/S0A2U53QCuF8HbRY4Ri D9lJMUCkKff8jVSqVtINEw0zaDgnv2awLIO/v6YDVfglskwTcytIGy6TggOoxEoW9m 8sVkdmcHFCZ63WjGQ5kyLJio9uGAwNHGCZvUuecU=
Message-Id: <6.2.5.6.2.20110811234936.0bbcdde8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 12 Aug 2011 00:31:26 -0700
To: Brian E Carpenter 
From: SM 
Subject: Re: A6 record status
In-Reply-To: <4E447C7E.30202@gmail.com>
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com>  <22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <20110811234742.C922612BD870@drugs.dv.isc.org> <4E447C7E.30202@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 6man 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 07:38:40 -0000

Hi Brian,
At 18:06 11-08-2011, Brian E Carpenter wrote:
>If it's historic, servers shouldn't even contain any A6 records,
>surely?

It only means that there is consensus within the IETF to classify the 
specification as Historic.  The A6 records won't disappear overnight though.

I suggest discussing about the paperwork on the DNSEXT mailing list.

Regards,
-sm 


From jiangsheng@huawei.com  Fri Aug 12 00:42:46 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD2821F84D7 for ; Fri, 12 Aug 2011 00:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.23
X-Spam-Level: 
X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.369,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vW8e9x2G29s for ; Fri, 12 Aug 2011 00:42:45 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5F81221F856D for ; Fri, 12 Aug 2011 00:42:45 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPT00M4P1DZWT@szxga05-in.huawei.com> for ipv6@ietf.org; Fri, 12 Aug 2011 15:41:59 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPT00DVR1DED8@szxga05-in.huawei.com> for ipv6@ietf.org; Fri, 12 Aug 2011 15:41:59 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119])	by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADD05142; Fri, 12 Aug 2011 15:41:57 +0800 (CST)
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 12 Aug 2011 15:41:50 +0800
Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.17]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Fri, 12 Aug 2011 15:41:54 +0800
Date: Fri, 12 Aug 2011 07:41:53 +0000
From: Sheng Jiang 
Subject: RE: A6 record status
In-reply-to: <20110812071132.0B6CD12C1D5B@drugs.dv.isc.org>
X-Originating-IP: [10.110.98.152]
To: Mark Andrews 
Message-id: <5D36713D8A4E7348A7E10DF7437A4B920122BEFD@SZXEML506-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: en-GB, zh-CN, en-US
Thread-topic: A6 record status
Thread-index: AQHMWKw7mIDSjNWJLka/OSinMjVthZUYuw+wgAAR/ZmAAAQ64A==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com>  <22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <20110811234742.C922612BD870@drugs.dv.isc.org> <4E447C7E.30202@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122BD2C@SZXEML506-MBS.china.huawei.com> <20110812071132.0B6CD12C1D5B@drugs.dv.isc.org>
Cc: Christian Huitema , Tim Chown , 6man , Brian E Carpenter , Tina TSOU 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 07:42:46 -0000

> > > In message <4E447C7E.30202@gmail.com>, Brian E Carpenter writes:
> > > > On 2011-08-12 11:47, Mark Andrews wrote:
> > > > > I think it is make work
> > > >
> > > > That's why I am only suggesting an IESG decision, not a draft
> > > > and an RFC.
> > > >
> > > > > and won't change the amount of confusion.
> > > > > In addition A6 allows compresssion of the domain name in the
> rdata
> > > > > so it can't be treated as unknown (i.e. a opaque blob) by
> > > nameservers.
> > > >
> > > > If it's historic, servers shouldn't even contain any A6 records,
> > > > surely?
> > >
> > > Making something historic doesn't remove the old software or the
> > > old records.  Removing knowledge of A6 from recursive server will
> > > result in garbage A6 records being delivered to old clients that
> > > are A6 aware.  A6 aware clients still work as they ask for both
> > > AAAA and A6 records.
> >
> > Yes, your statement are right. However, the case of A6 is there are
> few curre
> > nt A6 software or records. As far as I know, there are no commercial
> A6 suppo
> > rts in the current global DNS system. A6 only existed in some
> experimental sy
> > stem, like 6net. So, what we are worried here is not these existing
> A6. By mo
> > ving A6 into historic, we are preventing any NEW A6 implementation or
> deploym
> > ent.
> >
> > Sheng
> 
> The root servers are getting 100's of A6 q/s (~20:1 AAAA:A6
> ).  There is
> still a very large base of A6 using software out there regardless
> of whether they are getting NODATA responses or not.

Oops... This looks different from many people's thought. However, this is a fact that shows A6 is actually in use. Based on this, moving A6 to historic is much more complex than an IESG decision. We may need more investigation on how these A6 records are current used. We also need to investigate what impact may have if A6 is abolish. Another important question is whether there are A6-only client. It looks a lot investigation and analysis work, which is definitely worth a draft, before we can make the decision to moving A6 into history or start a phase out plan.

Sheng
 
> I don't know what percentage of responses are NODATA and what have
> actual A6 records.  I do think we need to know answers to these sorts
> of questions.
> 
> Mark
> 
> > > One needs a phase out plan if you want to remove A6 support and it
> > > is likely to need to be decades long given how long people run old
> > > nameservers for.
> > >
> > > > > If one wants to do something about IPv6 addresses in the DNS
> add
> > > > > support for scoped addresses.  Link-local could then be useful.
> > > >
> > > > Different topic, and I suspect much more complex.
> > > >
> > > >    Brian
> > > --
> > > Mark Andrews, ISC
> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> > > -------------------------------------------------------------------
> -
> > > IETF IPv6 working group mailing list
> > > ipv6@ietf.org
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > -------------------------------------------------------------------
> -
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From evyncke@cisco.com  Fri Aug 12 01:35:35 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD6521F86EE for ; Fri, 12 Aug 2011 01:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.244
X-Spam-Level: 
X-Spam-Status: No, score=-10.244 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtR90BNF6Kv9 for ; Fri, 12 Aug 2011 01:35:35 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C02B321F84F9 for ; Fri, 12 Aug 2011 01:35:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=3825; q=dns/txt; s=iport; t=1313138171; x=1314347771; h=mime-version:subject:date:message-id:references:from:to: cc; bh=4MCHT+2h+AkpG3QvrqmYE65Facc9DEOYO/czA3UPbM4=; b=Tk1H/K/6Eeo1DO81Dh0xFovFgakABFZ2I1oq+/mo2jK3EyXkpXqOdR/p 2eq5JnyFNdGrHpvY+lQYLoKFBgEFO4dIm4YuKsxmqFPIhBuaTNybyE4Cg Gx1qaKq3Nqanew8feeLUJuuzxtQyUeFna0pH6T7xnmzIKXcbdrYGz0WOy 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtsAAELkRE6Q/khN/2dsb2JhbABBmCCPTXeBQAEBAQEDAQEBDwEJEQM+CwwEAgEMDQMBAQELBhcBBgEgBh8JCAIEARIIGodRnTUBnmiFaF8EhzCQdIRfhn4
X-IronPort-AV: E=Sophos;i="4.67,360,1309737600"; d="scan'208,217";a="50171975"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 12 Aug 2011 08:33:49 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7C8XnYg022677; Fri, 12 Aug 2011 08:33:49 GMT
Received: from xmb-ams-110.cisco.com ([144.254.74.85]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 12 Aug 2011 10:33:49 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC58CA.8EE3723A"
Subject: =?iso-8859-1?Q?RE=A0=3A_A6_record_status?=
Date: Fri, 12 Aug 2011 10:33:44 +0200
Message-ID: <317616CE96204D49B5A1811098BA89501694A2@XMB-AMS-110.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: A6 record status
Thread-Index: AQHMWHLrmIDSjNWJLka/OSinMjVthZUYY04wgACA5I4=
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com><4E3F5166.8000605@gmail.com><5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com><750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk><4E406303.4040603@gmail.com><5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com><4E43378D.8070505@gmail.com><5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com><4E4345BB.5060103@gmail.com><5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com><4E445261.3040506@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122BB38@SZXEML506-MBS.china.huawei.com>
From: "Eric Vyncke (evyncke)" 
To: "Jiangsheng" , "Brian E Carpenter" , "6man" 
X-OriginalArrivalTime: 12 Aug 2011 08:33:49.0361 (UTC) FILETIME=[8F0E2A10:01CC58CA]
Cc: Tim Chown 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 08:35:35 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC58CA.8EE3723A
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

+1


-------- Message d'origine--------
De: ipv6-bounces@ietf.org de la part de Jiangsheng
Date: ven. 12-ao=FBt-11 02:57
=C0: Brian E Carpenter; 6man
Cc: Tim Chown
Objet : RE: A6 record status
=20
+1

When we did 6renum current practise analysis, we found A6 record is =
helpful in renumbering cases. However, we then found it has many issues, =
which has been documented in RFC 3363 and RFC 3364. If A6 stays =
experimental status, it is really misleading. We should avoid this =
confusion by moving it to Historic.

Sheng=20

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: Friday, August 12, 2011 6:06 AM
> To: 6man
> Cc: Jiangsheng; Tim Chown
> Subject: A6 record status
>=20
> Hi,
>=20
> What do 6man people think about moving RFC 2874 (the A6 record)
> from Experimental to Historic status?
>=20
> It's pretty clear that it doesn't have any real value, and
> it can still create confusion for newcomers.
>=20
> IMHO this doesn't need a draft; the IESG could just do it.
>=20
> Regards
>    Brian Carpenter
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


------_=_NextPart_001_01CC58CA.8EE3723A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE=A0: A6 record status





+1





-------- Message d'origine--------

De: ipv6-bounces@ietf.org de la part de Jiangsheng

Date: ven. 12-ao=FBt-11 02:57

=C0: Brian E Carpenter; 6man

Cc: Tim Chown

Objet : RE: A6 record status



+1



When we did 6renum current practise analysis, we found A6 record is =
helpful in renumbering cases. However, we then found it has many issues, =
which has been documented in RFC 3363 and RFC 3364. If A6 stays =
experimental status, it is really misleading. We should avoid this =
confusion by moving it to Historic.



Sheng



> -----Original Message-----

> From: Brian E Carpenter [mailto:brian.e.carpenter@gmai=
l.com]

> Sent: Friday, August 12, 2011 6:06 AM

> To: 6man

> Cc: Jiangsheng; Tim Chown

> Subject: A6 record status

>

> Hi,

>

> What do 6man people think about moving RFC 2874 (the A6 record)

> from Experimental to Historic status?

>

> It's pretty clear that it doesn't have any real value, and

> it can still create confusion for newcomers.

>

> IMHO this doesn't need a draft; the IESG could just do it.

>

> Regards

>    Brian Carpenter

--------------------------------------------------------------------

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/=
mailman/listinfo/ipv6

--------------------------------------------------------------------









------_=_NextPart_001_01CC58CA.8EE3723A--

From tjc@ecs.soton.ac.uk  Fri Aug 12 07:21:05 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD3F21F8ABD for ; Fri, 12 Aug 2011 07:21:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.024
X-Spam-Level: 
X-Spam-Status: No, score=-3.024 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJfEern+P1MZ for ; Fri, 12 Aug 2011 07:21:05 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id B2479228011 for ; Fri, 12 Aug 2011 07:21:04 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p7CELbn0031068; Fri, 12 Aug 2011 15:21:37 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p7CELbn0031068
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1313158897; bh=cFayfYm/KoyH/8RRjw2w5DD5dNM=; h=From:Date:Subject:To:Mime-Version:References; b=06/Pk+fMNDQ06kwFFyzXz5Pif9nhpbw0ige6MO9uV57Bq/z1Tk1nhcd4ztX6mxx7I lJ2DQGUji+lbFSIdgZ3FzlS5c1rQ1PIijuRa6KQtVDwgtBlG/HYneqBd4WMG9vwiwC r99Dfrw61KatDn+oPvR78spYWuRw2iDuToNTz8PE=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from  with ESMTP id n7BFLb0366105657dx ret-id none; Fri, 12 Aug 2011 15:21:37 +0100
Received: from [IPv6:2001:630:d0:f105:2022:c8dd:e23a:f927] ([IPv6:2001:630:d0:f105:2022:c8dd:e23a:f927]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p7CELUXt019016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Aug 2011 15:21:31 +0100
From: Tim Chown 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Aug 2011 15:21:30 +0100
Subject: Moving to WGLC 3484-bis?
To: Arifumi Matsumoto , 6man Mailing List ,  Brian Haberman 
Message-ID: 
Mime-Version: 1.0 (Apple Message framework v1244.3)
X-Mailer: Apple Mail (2.1244.3)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n7BFLb036610565700; tid=n7BFLb0366105657dx; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0
References: 
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: p7CELbn0031068
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 14:21:06 -0000

Hi guys,

I think we're almost ready to WGLC the 3484-bis draft, as per =
draft-ietf-6man-rfc3484-revise-04.

We had 3 issues in Quebec:

1) Inclusion of deprecated prefixes.  It seemed the agreement in the =
room was to include compatibles, site-locals and 6bone prefixes in the =
policy table.  If that's what we do, then we need to add 3ffe::/16 back =
in.

2) Privacy bit indicator.  We had removed the privacy bit indicator =
after the heavy negative feedback in Prague to a privacy bit option for =
RAs, but Eric Vyncke suggested it should be added back so that an =
enterprise administrator could use the DHCPv6 policy distribution method =
to have hosts in their domain not use privacy addresses for talking to =
other hosts in their domain (same prefix, or ULAs).  At the moment, =
there is no privacy bit support.

3) Prefer greatest lifetime.  We agreed to make no change here.

If we agree to add back 3ffe::/16, we could quickly produce a revise-05 =
and WGLC based on that, and ask in the WGLC whether there's strong =
support for the privacy option.  If there is, then the option bit itself =
would be defined in the DHCPv6 policy distribution text, and 3484-bis =
would need to describe the use of the bit in the updated policy table.=20=


Sound reasonable, or would a different approach be better?

Tim=

From drc@virtualized.org  Fri Aug 12 10:16:27 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC30A21F8745 for ; Fri, 12 Aug 2011 10:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHLpmq0HnAzB for ; Fri, 12 Aug 2011 10:16:27 -0700 (PDT)
Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0C29C21F85AC for ; Fri, 12 Aug 2011 10:16:26 -0700 (PDT)
Received: from [10.0.1.10] (cpe-66-91-109-17.hawaii.res.rr.com [66.91.109.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id E43941703F; Fri, 12 Aug 2011 17:17:03 +0000 (UTC)
Subject: Re: A6 record status
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: David Conrad 
In-Reply-To: <20110812071132.0B6CD12C1D5B@drugs.dv.isc.org>
Date: Fri, 12 Aug 2011 07:17:01 -1000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com>  <22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <20110811234742.C922612BD870@drugs.dv.isc.org> <4E447C7E.30202@gmail.com> <20110812045644.39BF212BFBCF@drugs.dv.isc.or g> <5D36713D8A4E7348A7E10DF7437A4B920122BD2C@SZXEML506-MBS.china.huawei.com> <20110812071132.0B6CD12C1D5B@drugs.dv.isc.org>
To: Mark Andrews 
X-Mailer: Apple Mail (2.1244.3)
Cc: 6man 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 17:16:28 -0000

Mark,

On Aug 11, 2011, at 9:11 PM, Mark Andrews wrote:
> The root servers are getting 100's of A6 q/s (~20:1 AAAA:A6
> ). =20

Yeah, so?  The vast majority of the queries hitting the root servers are =
useless crap.  100's of A6 qps is in the noise.

> There is
> still a very large base of A6 using software out there regardless
> of whether they are getting NODATA responses or not.

And keeping an RFC as experimental is going to change that how?

> I don't know what percentage of responses are NODATA and what have
> actual A6 records.  I do think we need to know answers to these sorts
> of questions.

Why?  What possible difference will it make?

Regards,
-drc


From brian@innovationslab.net  Fri Aug 12 13:15:32 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE0521F86BB for ; Fri, 12 Aug 2011 13:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0gyvU7iD4G5 for ; Fri, 12 Aug 2011 13:15:32 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2892821F8834 for ; Fri, 12 Aug 2011 13:15:32 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 309328816C; Fri, 12 Aug 2011 13:16:10 -0700 (PDT)
Received: from clemson.local (unknown [75.94.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 095811368394; Fri, 12 Aug 2011 13:16:08 -0700 (PDT)
Message-ID: <4E4589FD.50008@innovationslab.net>
Date: Fri, 12 Aug 2011 16:15:57 -0400
From: Brian Haberman 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Tim Chown 
Subject: Re: Moving to WGLC 3484-bis?
References:  
In-Reply-To: 
X-Enigmail-Version: 1.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 6man Mailing List 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 20:15:32 -0000

Hi Tim,

On 8/12/11 10:21 AM, Tim Chown wrote:
> Hi guys,
> 
> I think we're almost ready to WGLC the 3484-bis draft, as per
> draft-ietf-6man-rfc3484-revise-04.
> 
> We had 3 issues in Quebec:
> 
> 1) Inclusion of deprecated prefixes.  It seemed the agreement in the
> room was to include compatibles, site-locals and 6bone prefixes in
> the policy table.  If that's what we do, then we need to add
> 3ffe::/16 back in.
> 
> 2) Privacy bit indicator.  We had removed the privacy bit indicator
> after the heavy negative feedback in Prague to a privacy bit option
> for RAs, but Eric Vyncke suggested it should be added back so that an
> enterprise administrator could use the DHCPv6 policy distribution
> method to have hosts in their domain not use privacy addresses for
> talking to other hosts in their domain (same prefix, or ULAs).  At
> the moment, there is no privacy bit support.
> 
> 3) Prefer greatest lifetime.  We agreed to make no change here.
> 
> If we agree to add back 3ffe::/16, we could quickly produce a
> revise-05 and WGLC based on that, and ask in the WGLC whether there's
> strong support for the privacy option.  If there is, then the option
> bit itself would be defined in the DHCPv6 policy distribution text,
> and 3484-bis would need to describe the use of the bit in the updated
> policy table.

I agree with your assessment and this approach as a reasonable way
forward.  Go ahead and generate -05 with 3ffe::/16 back in the table.
When that draft is out, I will start a WG Last Call and specifically
request feedback on the privacy bit issue.

Regards,
Brian


From brian.e.carpenter@gmail.com  Fri Aug 12 13:53:09 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FAD11E8091 for ; Fri, 12 Aug 2011 13:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T89MK1HNV-yZ for ; Fri, 12 Aug 2011 13:53:08 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A93DF11E8088 for ; Fri, 12 Aug 2011 13:53:07 -0700 (PDT)
Received: by bkar4 with SMTP id r4so2316901bka.31 for ; Fri, 12 Aug 2011 13:53:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0BgYigCeDdoZRVo9V+tnv/GfRCUY76qvaY7zqL2A6X0=; b=oDJyvn6zuzM2EjNaTHm/p378cEXI4iv3TCe0UI70REkcZQJlZiyMj10MHahj46L1bz VvkZ1rvaBUG1sRi0KhzbpjbLNbkZ4+a9xlCkxGdLAK1LzGFGHEThCPF7h4wVsHsZH8lZ 8BCD8zoGlIFr0v4jGOPrZyHeDkFBqXNr0cdS4=
Received: by 10.204.241.14 with SMTP id lc14mr551199bkb.322.1313182423089; Fri, 12 Aug 2011 13:53:43 -0700 (PDT)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id q1sm10132faa.1.2011.08.12.13.53.39 (version=SSLv3 cipher=OTHER); Fri, 12 Aug 2011 13:53:41 -0700 (PDT)
Message-ID: <4E4592CB.8020508@gmail.com>
Date: Sat, 13 Aug 2011 08:53:31 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: David Conrad 
Subject: Re: A6 record status
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com>	<4E406303.4040603@gmail.com>	<5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com>	<4E43378D.8070505@gmail.com>	<5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com>	<4E4345BB.5060103@gmail.com>	<5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com>	<4E445261.3040506@gmail.com>		<22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>	<20110811234742.C922612BD870@drugs.dv.isc.org>	<4E447C7E.30202@gmail.com>	<20110812045644.39BF212BFBCF@drugs.dv.isc.or g>	<5D36713D8A4E7348A7E10DF7437A4B920122BD2C@SZXEML506-MBS.china.huawei.com>	<20110812071132.0B6CD12C1D5B@drugs.dv.isc.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: 6man , Mark Andrews 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 20:53:09 -0000

I agree that the status of the RFC has no immediate or direct
impact on the real world. But I think it's orthogonal to the
*operational* question of how to eliminate the residual A6
records and how to eventually eliminate A6 queries. Mark is
completely correct that this would require a plan - but since
it's a purely operational matter, presumably it belongs in DNSOP
if it belongs anywhere in the IETF.

Marking the RFC as Historic would only be the first step,
apparently.

Regards
   Brian

On 2011-08-13 05:17, David Conrad wrote:
> Mark,
> 
> On Aug 11, 2011, at 9:11 PM, Mark Andrews wrote:
>> The root servers are getting 100's of A6 q/s (~20:1 AAAA:A6
>> ).  
> 
> Yeah, so?  The vast majority of the queries hitting the root servers are useless crap.  100's of A6 qps is in the noise.
> 
>> There is
>> still a very large base of A6 using software out there regardless
>> of whether they are getting NODATA responses or not.
> 
> And keeping an RFC as experimental is going to change that how?
> 
>> I don't know what percentage of responses are NODATA and what have
>> actual A6 records.  I do think we need to know answers to these sorts
>> of questions.
> 
> Why?  What possible difference will it make?
> 
> Regards,
> -drc
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

From rdroms.ietf@gmail.com  Fri Aug 12 14:27:50 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D175811E8088 for ; Fri, 12 Aug 2011 14:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.203
X-Spam-Level: 
X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1,  USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTAxP-gQsIzs for ; Fri, 12 Aug 2011 14:27:50 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3F421F8834 for ; Fri, 12 Aug 2011 14:27:09 -0700 (PDT)
Received: by vws12 with SMTP id 12so3447589vws.31 for ; Fri, 12 Aug 2011 14:27:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=kBXDsi5/IAr9tBstq562WRyfK2CYBq9L/DWUAcjaC2I=; b=MLMJkiUJAynqb5RCAeZ/Mdu7o31hTyKWoWH//7oJbZkr+Ec4fQoMgx0vNuZeI9uS2v 3ypj0o1ApZ4UDlpRehNHT/FBfQe17I6fHqt2HTtX2wkhlf5jjS7Ajs5sQm6HEdEYxfq+ GytTRcBHNQlFOA1Xhfu1/AnTmQpY2S252hHZs=
Received: by 10.52.21.104 with SMTP id u8mr1211990vde.409.1313184465995; Fri, 12 Aug 2011 14:27:45 -0700 (PDT)
Received: from [10.82.201.210] (mobile-166-137-136-181.mycingular.net [166.137.136.181]) by mx.google.com with ESMTPS id h4sm1466693vcx.21.2011.08.12.14.27.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Aug 2011 14:27:44 -0700 (PDT)
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com>  <22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <20110811234742.C922612BD870@drugs.dv.isc.org> <4E447C7E.30202@gmail.com> <20110812045644.39BF212BFBCF@drugs.dv.isc.or g>
In-Reply-To: <20110812045644.39BF212BFBCF@drugs.dv.isc.org>
Mime-Version: 1.0 (iPhone Mail 8L1)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <0F7C7E7F-8E24-453D-91FA-7FC8AA891CB9@gmail.com>
X-Mailer: iPhone Mail (8L1)
From: Ralph Droms 
Subject: Re: A6 record status
Date: Fri, 12 Aug 2011 17:27:36 -0400
To: Mark Andrews 
Cc: Christian Huitema , Tim Chown , 6man , Brian E Carpenter , Tina TSOU 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 21:27:50 -0000

Mark - do you have any estimate of the current use of A6 records?  I'd like t=
o get an idea of the scope of the impact of moving A6 records to Historic.

- Ralph



On Aug 12, 2011, at 12:56 AM, Mark Andrews  wrote:

>=20
> In message <4E447C7E.30202@gmail.com>, Brian E Carpenter writes:
>> On 2011-08-12 11:47, Mark Andrews wrote:
>>> I think it is make work=20
>>=20
>> That's why I am only suggesting an IESG decision, not a draft
>> and an RFC.
>>=20
>>> and won't change the amount of confusion.
>>> In addition A6 allows compresssion of the domain name in the rdata
>>> so it can't be treated as unknown (i.e. a opaque blob) by nameservers.
>>=20
>> If it's historic, servers shouldn't even contain any A6 records,
>> surely?
>=20
> Making something historic doesn't remove the old software or the
> old records.  Removing knowledge of A6 from recursive server will
> result in garbage A6 records being delivered to old clients that
> are A6 aware.  A6 aware clients still work as they ask for both
> AAAA and A6 records.
>=20
> One needs a phase out plan if you want to remove A6 support and it
> is likely to need to be decades long given how long people run old
> nameservers for.
>=20
>>> If one wants to do something about IPv6 addresses in the DNS add
>>> support for scoped addresses.  Link-local could then be useful.
>>=20
>> Different topic, and I suspect much more complex.
>>=20
>>   Brian
> --=20
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

From drc@virtualized.org  Fri Aug 12 15:26:41 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C078321F86AD for ; Fri, 12 Aug 2011 15:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgan-rGky07V for ; Fri, 12 Aug 2011 15:26:41 -0700 (PDT)
Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2477221F86AB for ; Fri, 12 Aug 2011 15:26:41 -0700 (PDT)
Received: from [10.0.1.10] (cpe-66-91-109-17.hawaii.res.rr.com [66.91.109.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id E29391703F; Fri, 12 Aug 2011 22:27:14 +0000 (UTC)
Subject: Re: A6 record status
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: David Conrad 
In-Reply-To: <4E4592CB.8020508@gmail.com>
Date: Fri, 12 Aug 2011 12:27:12 -1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E07EA26-4366-4F4B-833A-C04569808B2C@virtualized.org>
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com>	<4E406303.4040603@gmail.com>	<5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com>	<4E43378D.8070505@gmail.com>	<5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com>	<4E4345BB.5060103@gmail.com>	<5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com>	<4E445261.3040506@gmail.com>		<22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com>	<20110811234742.C922612BD870@drugs.dv.isc.org>	<4E447C7E.30202@gmail.com>	<20110812045644.39BF212BFBCF@drugs.dv.isc.or g>	<5D36713D8A4E7348A7E10DF7437A4B920122BD2C@SZXEML506-MBS.china.huawei.com>	<20110812071132.0B6CD12C1D5B@drugs.dv.isc.org>  <4E4592CB.8020508@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1244.3)
Cc: 6man 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 22:26:41 -0000

Brian,

On Aug 12, 2011, at 10:53 AM, Brian E Carpenter wrote:
> But I think it's orthogonal to the
> *operational* question of how to eliminate the residual A6
> records and how to eventually eliminate A6 queries.

If you can figure this out, perhaps the lesson can be applied to =
iqueries and queries to root servers that changed IP addresses over a =
decade ago.

> Mark is
> completely correct that this would require a plan - but since
> it's a purely operational matter, presumably it belongs in DNSOP
> if it belongs anywhere in the IETF.

I believe the issue is folks not upgrading name servers. Mark can =
correct me if I'm wrong, but the reason there are so many A6 queries is =
because back in the late 90s when BINDv9 was being written, A6 was going =
to be the future. As a result, A6 queries were tried by default (I think =
they were actually tried before AAAA in BIND 9.{0,1,2} but not =
positive). When it was pointed out that A6 had some fundamental issues =
(discussed in http://tools.ietf.org/html/draft-ietf-dnsext-aaaa-a6-01 =
with the deprecation codified in RFC 3363), A6 was abandoned in favor of =
AAAA and BINDv9 no longer tried A6 records by default.  I believe A6 was =
removed from the query order in 2004 or 2005.

> Marking the RFC as Historic would only be the first step, apparently.

Wouldn't hurt, but I doubt any sort of RFC action will have a =
significant impact.  We're in the long tail of old software getting =
flushed out of the Internet.

Regards,
-drc


From marka@isc.org  Fri Aug 12 18:37:22 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC0421F84D5 for ; Fri, 12 Aug 2011 18:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+xcx84sOoU6 for ; Fri, 12 Aug 2011 18:37:22 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id A6A9F21F84D4 for ; Fri, 12 Aug 2011 18:37:21 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 5751E5F988D; Sat, 13 Aug 2011 01:37:34 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6E84D216C7B; Sat, 13 Aug 2011 01:37:32 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 8D25E12C40F9; Sat, 13 Aug 2011 11:37:29 +1000 (EST)
To: Ralph Droms 
From: Mark Andrews 
References: <5D36713D8A4E7348A7E10DF7437A4B9201228398@SZXEML506-MBS.china.huawei.com> <4E3F5166.8000605@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B9201228515@SZXEML506-MBS.china.huawei.com> <750E838E-3962-4893-A2D0-012576A1BF36@ecs.soton.ac.uk>  <4E406303.4040603@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B288@SZXEML506-MBS.china.huawei.com> <4E43378D.8070505@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B2E1@SZXEML506-MBS.china.huawei.com> <4E4345BB.5060103@gmail.com> <5D36713D8A4E7348A7E10DF7437A4B920122B36A@SZXEML506-MBS.china.huawei.com> <4E445261.3040506@gmail.com>  <22F6318E46E26B498ABC828879B08D4F1786A07E@TK5EX14MBXW652.wingroup.windeploy.ntdev.microsoft.com> <20110811234742.C922612BD870@drugs.dv.isc.org> <4E447C7E.30202@gmail.com> <20110812045644.39BF212BFBCF@drugs.dv.isc.or g>  <0F7C7E7F-8E24-453D-91FA-7FC8AA891CB9@gmail.com>
Subject: Re: A6 record status
In-reply-to: Your message of "Fri, 12 Aug 2011 17:27:36 -0400." <0F7C7E7F-8E24-453D-91FA-7FC8AA891CB9@gmail.com>
Date: Sat, 13 Aug 2011 11:37:29 +1000
Message-Id: <20110813013729.8D25E12C40F9@drugs.dv.isc.org>
Cc: Christian Huitema , Tim Chown , 6man , Brian E Carpenter , Tina TSOU 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Aug 2011 01:37:22 -0000

In message <0F7C7E7F-8E24-453D-91FA-7FC8AA891CB9@gmail.com>, Ralph Droms writes
:
> Mark - do you have any estimate of the current use of A6 records?  I'd like t
> =
> o get an idea of the scope of the impact of moving A6 records to Historic.
> 
> - Ralph

The passive DNS sensors saw no A6 records in June and July.
 
Mark

> On Aug 12, 2011, at 12:56 AM, Mark Andrews  wrote:
> 
> >=20
> > In message <4E447C7E.30202@gmail.com>, Brian E Carpenter writes:
> >> On 2011-08-12 11:47, Mark Andrews wrote:
> >>> I think it is make work=20
> >>=20
> >> That's why I am only suggesting an IESG decision, not a draft
> >> and an RFC.
> >>=20
> >>> and won't change the amount of confusion.
> >>> In addition A6 allows compresssion of the domain name in the rdata
> >>> so it can't be treated as unknown (i.e. a opaque blob) by nameservers.
> >>=20
> >> If it's historic, servers shouldn't even contain any A6 records,
> >> surely?
> >=20
> > Making something historic doesn't remove the old software or the
> > old records.  Removing knowledge of A6 from recursive server will
> > result in garbage A6 records being delivered to old clients that
> > are A6 aware.  A6 aware clients still work as they ask for both
> > AAAA and A6 records.
> >=20
> > One needs a phase out plan if you want to remove A6 support and it
> > is likely to need to be decades long given how long people run old
> > nameservers for.
> >=20
> >>> If one wants to do something about IPv6 addresses in the DNS add
> >>> support for scoped addresses.  Link-local could then be useful.
> >>=20
> >> Different topic, and I suspect much more complex.
> >>=20
> >>   Brian
> > --=20
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From rdroms@gmail.com  Fri Aug 12 14:35:08 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D2E21F88A6; Fri, 12 Aug 2011 14:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level: 
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dixaZLkO8ZxD; Fri, 12 Aug 2011 14:35:07 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 15EC521F88A5; Fri, 12 Aug 2011 14:35:05 -0700 (PDT)
Received: by vxi29 with SMTP id 29so3406685vxi.31 for ; Fri, 12 Aug 2011 14:35:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; bh=uR1T6y60ULQ8bWc1TRa+82z9nxZdpcXa040Hns2ZQaQ=; b=k8wPrUD31RPrLAvcUkfTxtVOADOs6iPEHz9RA5TclazdMTiEEVeaDpJeuv4U7GQ6B8 daCaQpj4iEobu+DQSXSOusLHHLSmCAOJWz9EsR1dGUyml3EEgDAB874EpKuUXI4NYGnz YbKeVsgKXkYbqN4FebW1c99peyW5ZVSGtatDo=
Received: by 10.52.180.102 with SMTP id dn6mr1289884vdc.51.1313184942969; Fri, 12 Aug 2011 14:35:42 -0700 (PDT)
Received: from [10.82.201.210] (mobile-166-137-136-181.mycingular.net [166.137.136.181]) by mx.google.com with ESMTPS id k10sm2170815vdi.43.2011.08.12.14.35.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Aug 2011 14:35:41 -0700 (PDT)
Subject: A6 to Historic
From: Ralph Droms 
Content-Type: text/plain; charset=us-ascii
X-Mailer: iPhone Mail (8L1)
Message-Id: <44172923-8ECC-44D4-A4DE-8040EF94CBC3@gmail.com>
Date: Fri, 12 Aug 2011 17:35:35 -0400
To: "dnsext@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (iPhone Mail 8L1)
X-Mailman-Approved-At: Fri, 12 Aug 2011 20:19:08 -0700
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 Aug 2011 21:35:08 -0000

There has been a discussion on the 6man mailing list about moving A6 records=
 to Historic.  I'd like to get input from dnsext about the re-designation.

ipv6@ietf.org is bcc:ed; please reply to dnsext.

Thanks

- Ralph


From v6ops@globis.net  Sat Aug 13 03:17:00 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4213521F856C for ; Sat, 13 Aug 2011 03:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level: 
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w6ngRkZ-kvd for ; Sat, 13 Aug 2011 03:16:59 -0700 (PDT)
Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id B6F6D21F8779 for ; Sat, 13 Aug 2011 03:16:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AF2868700ED; Sat, 13 Aug 2011 12:17:36 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdZUtyse00ZI; Sat, 13 Aug 2011 12:17:29 +0200 (CEST)
Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id B8B9B8700C7; Sat, 13 Aug 2011 12:17:29 +0200 (CEST)
Message-ID: <4E464F39.8060305@globis.net>
Date: Sat, 13 Aug 2011 12:17:29 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Tim Chown 
Subject: re: Moving to WGLC 3484-bis?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Brian Haberman , 6man Mailing List 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Aug 2011 10:17:00 -0000

I still think there's an issue with the suggested blanket global 
treatment of IPv4 RFC1918 addresses.

Quote draft-ietf-6man-rfc3484-revise-04 "This issue can be fixed by changing the
address scope of private IPv4 addresses to global."

IMVHO I think it is highly likely that over time this assumption will not hold true:
think end game when IPv6 native only networks are widely deployed and CGN is turned off.
At that time there's still probably going to be many (local) NAT boxes
that advertise an IPv4 default route and serve RFC1918 DHCP addresses to clients,
but cannot provide global connectivity.

So whatever you assume about RFC1918 addresses has a good chance of being incorrect
unless you can truly detect/confirm presence of global IPv4 connectivity via NAT.

I therefore suggest: "a host MAY/SHOULD attempt to determine appropriate characterization
of RFC1918 address scope (local or global) on an individual basis
e.g. via local configuration, or by connecting to a well known server on
the public Internet upon interface initiation, and asking for a reflection of
their own client IPv4 address. In the absence of further information,
a host SHOULD assume that RFC 1918 addresses are to be treated as"

You can then debate whether the default  should be "global" or "local".

regards,
RayH


> Message: 3
> Date: Fri, 12 Aug 2011 15:21:30 +0100
> From: Tim Chown
> To: Arifumi Matsumoto, 6man Mailing List
> 	, 	Brian Haberman
> Subject: Moving to WGLC 3484-bis?
> Message-ID:
> 	
> 	
> Content-Type: text/plain; charset=us-ascii
>
> Hi guys,
>
> I think we're almost ready to WGLC the 3484-bis draft, as per draft-ietf-6man-rfc3484-revise-04.
>
> We had 3 issues in Quebec:
>
> 1) Inclusion of deprecated prefixes.  It seemed the agreement in the room was to include compatibles, site-locals and 6bone prefixes in the policy table.  If that's what we do, then we need to add 3ffe::/16 back in.
>
> 2) Privacy bit indicator.  We had removed the privacy bit indicator after the heavy negative feedback in Prague to a privacy bit option for RAs, but Eric Vyncke suggested it should be added back so that an enterprise administrator could use the DHCPv6 policy distribution method to have hosts in their domain not use privacy addresses for talking to other hosts in their domain (same prefix, or ULAs).  At the moment, there is no privacy bit support.
>
> 3) Prefer greatest lifetime.  We agreed to make no change here.
>
> If we agree to add back 3ffe::/16, we could quickly produce a revise-05 and WGLC based on that, and ask in the WGLC whether there's strong support for the privacy option.  If there is, then the option bit itself would be defined in the DHCPv6 policy distribution text, and 3484-bis would need to describe the use of the bit in the updated policy table.
>
> Sound reasonable, or would a different approach be better?
>
> Tim
>
>    

From pch-b29AA871B@u-1.phicoh.com  Sat Aug 13 05:48:05 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC0321F877F for ; Sat, 13 Aug 2011 05:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.562
X-Spam-Level: 
X-Spam-Status: No, score=-4.562 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtaWPT4SCrwD for ; Sat, 13 Aug 2011 05:48:05 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo-6to4.hq.phicoh.net [IPv6:2002:8225:f03:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0721F84F9 for ; Sat, 13 Aug 2011 05:48:01 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #66) id m1QsDdn-0001i3C; Sat, 13 Aug 2011 14:48:39 +0200
Message-Id: 
To: Ray Hunter 
Subject: Re: Moving to WGLC 3484-bis? 
From: Philip Homburg 
Sender: pch-b29AA871B@u-1.phicoh.com
In-reply-to: Your message of "Sat, 13 Aug 2011 12:17:29 +0200 ." <4E464F39.8060305@globis.net> 
Date: Sat, 13 Aug 2011 14:48:17 +0200
Cc: 6man Mailing List 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 13 Aug 2011 12:48:05 -0000

In your letter dated Sat, 13 Aug 2011 12:17:29 +0200 you wrote:
>I still think there's an issue with the suggested blanket global 
>treatment of IPv4 RFC1918 addresses.
>
>Quote draft-ietf-6man-rfc3484-revise-04 "This issue can be fixed by changing t
>he
>address scope of private IPv4 addresses to global."
>
>IMVHO I think it is highly likely that over time this assumption will not hold
> true:
>think end game when IPv6 native only networks are widely deployed and CGN is t
>urned off.
>At that time there's still probably going to be many (local) NAT boxes
>that advertise an IPv4 default route and serve RFC1918 DHCP addresses to clien
>ts,
>but cannot provide global connectivity.
>
>So whatever you assume about RFC1918 addresses has a good chance of being inco
>rrect
>unless you can truly detect/confirm presence of global IPv4 connectivity via N
>AT.

Ah, tricky.

For destination addresses we have 3 possibilities: v4-only, v6-only, and
dual-stack.

Obviously, without global IPv4 connectivity, connecting to v4-only destinations
is not going to work, no matter what you put in the policy table. Connecting
to v6-only destinations doesn't involve v4, so that's not an issue either.

For dual stack, connecting over v6 is preferred unless one v6 address is 
6to4 or teredo. Given that you are unlikely to have 6to4 or teredo in
that kind of environment, that's not going to be the local address.

So there is one remaining corner case. If the remote address is 6to4 or
teredo, then the policy table will prefer IPv4.

I'm not sure it's worth making thing more complex just o handle this corner
case.



From rdroms.ietf@gmail.com  Mon Aug 15 21:44:06 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B24221F8B1C; Mon, 15 Aug 2011 21:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.559
X-Spam-Level: 
X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OkQByq-aQkO; Mon, 15 Aug 2011 21:44:05 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5D28C21F8ADC; Mon, 15 Aug 2011 21:44:05 -0700 (PDT)
Received: by qyk35 with SMTP id 35so3134517qyk.10 for ; Mon, 15 Aug 2011 21:44:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer; bh=1XeYdudLkL2J//T1L/qY/iUieTIchTucuw8OPNcibEw=; b=h6lwymYxcDHtqtGrSr0n6QihxprlpRjZB0HNJHE21LF+fA9NzSkFbHg/IlAkt3nJC3 es7c01dXwI/zkQ3uM7I4RcvmlePr4fQpXKImsKlG9emFgP2+U2juW+n7nha4JCiiWq7M 9uZ8ttcmebOr9JbNp/HDYyzBCV3YvyB+rQ0dA=
Received: by 10.224.30.211 with SMTP id v19mr3121716qac.136.1313469892499; Mon, 15 Aug 2011 21:44:52 -0700 (PDT)
Received: from bxb-rdroms-8714.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id k14sm4652986qct.45.2011.08.15.21.44.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Aug 2011 21:44:51 -0700 (PDT)
From: Ralph Droms 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 16 Aug 2011 00:44:48 -0400
Subject: A6 to Historic
To: "dnsext@ietf.org" 
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Tue, 16 Aug 2011 00:26:27 -0700
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 04:44:06 -0000

There has been a discussion on the 6man mailing list about moving A6 =
records to Historic.  I'd like to get input from dnsext about the =
re-designation.

ipv6@ietf.org is bcc:ed; please reply to dnsext.

Thanks

- Ralph


From tjc@ecs.soton.ac.uk  Tue Aug 16 04:11:17 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0146521F8AD3 for ; Tue, 16 Aug 2011 04:11:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level: 
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3dwlwhjrRDm for ; Tue, 16 Aug 2011 04:11:16 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id E3E5421F8AC3 for ; Tue, 16 Aug 2011 04:11:15 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p7GBBx9j013349 for ; Tue, 16 Aug 2011 12:11:59 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p7GBBx9j013349
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1313493119; bh=Mt4DwxCxAikay9psCrsWRxIxXwo=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=waeGXWnvTDVBvdLUbQyVFNLfI+N1rm3fbc03c//sQyZ7+Ux+2azTMTsdiLTB2oa1L ycISZUKD97RfXB42zeaA8iEA59S40E/veFWoOwO6dDlVfmYmeXdviNJH445cuDotgU xB/uJAK5nGsUZElMxWK/3HT0YhC3iyenC72yJOYA=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from  with ESMTP id n7FCBx0366124195XJ ret-id none; Tue, 16 Aug 2011 12:11:59 +0100
Received: from dhcp-152-78-94-241.ecs.soton.ac.uk (dhcp-152-78-94-241.ecs.soton.ac.uk [152.78.94.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p7GBBt7B007286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 16 Aug 2011 12:11:55 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1244.3)
Subject: Re: RFC 3306 question
From: Tim Chown 
In-Reply-To: <4E428D83.4060501@innovationslab.net>
Date: Tue, 16 Aug 2011 12:11:55 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References:  <4E428D83.4060501@innovationslab.net> <7A786539-A2AD-4B53-8FAF-86689969720E@ecs.soton.ac.uk>
To: 6man Mailing List 
X-Mailer: Apple Mail (2.1244.3)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n7FCBx036612419500; tid=n7FCBx0366124195XJ; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: p7GBBx9j013349
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 11:11:17 -0000

On 10 Aug 2011, at 14:54, Brian Haberman wrote:

> On 8/9/11 5:51 PM, Kerry Lynn wrote:
>> RFC 3306 states:
>>=20
>>=20
>> "The scope of the unicast-prefix based multicast address MUST NOT
>> exceed the scope of the unicast prefix embedded in the multicast
>> address."
>>=20
>>=20
>> I'd just like to verify my interpretation that site-local multicast =
addresses
>>=20
>> MAY be formed from ULA prefixes?  If so, should a particular value
>=20
> Yes, there is no issue with using a ULA prefix to form a =
unicast-prefix
> based multicast address with site-local scope.

Or presumably across whatever scope over which the ULA applies.  In our =
university we use site scope multicast (5) for departments and =
organisation scope multicast (8) for services constrained to the =
university.   If we used ULAs, then there would be a single /48 ULA for =
the university.

Technically RFC3306 would permit a global scope (e) multicast address =
using a ULA prefix, at least by the text cited above from the end of =
section 4.  That is a nit caused by the change in scope between =
deprecated site-locals and newer ULAs.

In practice we use Embedded-RP for all our IPv6 multicast. The embedded =
RP address could presumably be ULA so long as the multicast was only =
carried within the organisation border where the ULA routing existed.   =
It's not something we've tried to do, but it would theoreticially give =
some improved independence from network renumbering events.

This topic may become more relevant if ULAs are discussed more widely =
for routed networks in homenet, and 'home scope' service discovery (for =
example) used multicast.

Tim


From evyncke@cisco.com  Tue Aug 16 05:12:20 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F46021F883A for ; Tue, 16 Aug 2011 05:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.398
X-Spam-Level: 
X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1zl5auZLucX for ; Tue, 16 Aug 2011 05:12:19 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AE32721F8880 for ; Tue, 16 Aug 2011 05:12:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=2054; q=dns/txt; s=iport; t=1313496787; x=1314706387; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=/3R8J3iy5TNHMBtw8nirb5wuYoWWFghFCMPNNa1H/1M=; b=DK64MRN9WOSGlBntYgVOahtiq7rlSP2enj+g5mWA4AlLktQ0DqKW19/X cilXZA3QnkRzxprvO53nXvZPdT/CezdSuXMBFzWRwEy0wu9PnfGAPS/9t YprstGk0P7Bz+3eNDmizQmiVHHpQ9PFNMOxCnKTxgh37syE7KxoP/tRWX o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAO1dSk6Q/khM/2dsb2JhbABBDqgjd4FAAQEBAQMBAQEPAR0+FwQCAQgOAwQBAQsGFwEGASYfCQgBAQQBEggah1KaRgGfLoVoXwSHMJB3iyg6
X-IronPort-AV: E=Sophos;i="4.67,380,1309737600"; d="scan'208";a="50704363"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 16 Aug 2011 12:13:01 +0000
Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7GCD1OQ001506; Tue, 16 Aug 2011 12:13:01 GMT
Received: from xmb-ams-110.cisco.com ([144.254.74.85]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 16 Aug 2011 14:13:02 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Moving to WGLC 3484-bis?
Date: Tue, 16 Aug 2011 14:13:00 +0200
Message-ID: <317616CE96204D49B5A1811098BA89500529B107@XMB-AMS-110.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Moving to WGLC 3484-bis?
Thread-Index: AcxY+zLGybrNDaXyTXSIKMTJqhCAIwDEpTTQ
References:  
From: "Eric Vyncke (evyncke)" 
To: "Tim Chown" , "Arifumi Matsumoto" , "6man Mailing List" , "Brian Haberman" 
X-OriginalArrivalTime: 16 Aug 2011 12:13:02.0082 (UTC) FILETIME=[D8571E20:01CC5C0D]
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 Aug 2011 12:12:20 -0000

BTW, ok for me of course to go WGLC even without the privacy bit =
indicator

-=E9ric

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf =
Of Tim
> Chown
> Sent: vendredi 12 ao=FBt 2011 16:22
> To: Arifumi Matsumoto; 6man Mailing List; Brian Haberman
> Subject: Moving to WGLC 3484-bis?
>=20
> Hi guys,
>=20
> I think we're almost ready to WGLC the 3484-bis draft, as per =
draft-ietf-
> 6man-rfc3484-revise-04.
>=20
> We had 3 issues in Quebec:
>=20
> 1) Inclusion of deprecated prefixes.  It seemed the agreement in the =
room was
> to include compatibles, site-locals and 6bone prefixes in the policy =
table.
> If that's what we do, then we need to add 3ffe::/16 back in.
>=20
> 2) Privacy bit indicator.  We had removed the privacy bit indicator =
after the
> heavy negative feedback in Prague to a privacy bit option for RAs, but =
Eric
> Vyncke suggested it should be added back so that an enterprise =
administrator
> could use the DHCPv6 policy distribution method to have hosts in their =
domain
> not use privacy addresses for talking to other hosts in their domain =
(same
> prefix, or ULAs).  At the moment, there is no privacy bit support.
>=20
> 3) Prefer greatest lifetime.  We agreed to make no change here.
>=20
> If we agree to add back 3ffe::/16, we could quickly produce a =
revise-05 and
> WGLC based on that, and ask in the WGLC whether there's strong support =
for
> the privacy option.  If there is, then the option bit itself would be =
defined
> in the DHCPv6 policy distribution text, and 3484-bis would need to =
describe
> the use of the bit in the updated policy table.
>=20
> Sound reasonable, or would a different approach be better?
>=20
> Tim
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

From wesley.george@twcable.com  Thu Aug 18 12:42:58 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5A221F8BDB for ; Thu, 18 Aug 2011 12:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.949
X-Spam-Level: 
X-Spam-Status: No, score=0.949 tagged_above=-999 required=5 tests=[AWL=-0.678,  BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368,  HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvnmZK99aH6j for ; Thu, 18 Aug 2011 12:42:56 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 82B8421F8BD8 for ; Thu, 18 Aug 2011 12:42:55 -0700 (PDT)
X-SENDER-IP: 10.136.163.15
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.68,247,1312171200";  d="scan'208,217";a="249317949"
Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 18 Aug 2011 15:40:25 -0400
Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.29]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 18 Aug 2011 15:43:49 -0400
From: "George, Wesley" 
To: Joel Jaeggli , "ipv6@ietf.org" 
Date: Thu, 18 Aug 2011 15:43:48 -0400
Subject: RE: Questions from the Authors of draft-gashinsky-v6nd-enhance
Thread-Topic: Questions from the Authors of draft-gashinsky-v6nd-enhance
Thread-Index: AcxVK5HH1yPGPue6R7KHjKfTrx0m6QIdwPcQ
Message-ID: <34E4F50CAFA10349A41E0756550084FB0C494F3F@PRVPEXVS04.corp.twcable.com>
References: <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com>
In-Reply-To: <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_34E4F50CAFA10349A41E0756550084FB0C494F3FPRVPEXVS04corpt_"
MIME-Version: 1.0
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 19:42:58 -0000

--_000_34E4F50CAFA10349A41E0756550084FB0C494F3FPRVPEXVS04corpt_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Joe=
l Jaeggli
Sent: Sunday, August 07, 2011 1:58 PM
To: ipv6@ietf.org
Subject: Questions from the Authors of draft-gashinsky-v6nd-enhance


1.      Is this document (draft-gashinsky-v6nd-enhance) worthwhile?

WEG] Yes

2. Is there critique of the two proposed 4861 changes?


            B. 7.4 ND cache priming and refresh
WEG] might be worth thinking about situations where DHCPv6 is in use and wh=
ether that can be leveraged to achieve something similar to this, i.e. watc=
h the DHCPv6 messages go past and pre-populate the ND cache accordingly.


2.      Should we separate the potential mitigations (section 6) and implem=
entation advice (section 7.1 and 7.2) into a separate document.

WEG] yes. I think that there's value in getting the explanation and short-t=
erm mitigation techniques out there sooner rather than later, and then if t=
here is consensus that there is protocol work to be done to further mitigat=
e the issue because the workarounds and tweaks discussed aren't enough on t=
heir own, the workarounds and discussion of the security issue aren't being=
 delayed by that protocol work.

            A. Assumption (validated in v6ops at ietf81) is that v6ops woul=
d be happy
             to take the mitigation and implementation advice as an informa=
tional document

            B. Assumption 2 a draft updating 4861 would be a standards trac=
k document.

            C. Assumption 3, should harmonize with  draft-nordmark-6man-imp=
atient-nud-00
WEG] Agree with all 3 assumptions.
Also, a comment on 7.1 - I think that this is roughly the right priority fo=
r certain applications, but not necessarily for all cases. In networks wher=
e it is more common for devices to be coming and going frequently, it may n=
ot be as appropriate to deprioritize traffic to unknown addresses. It may b=
e that in a lot of those applications, DHCPv6 will be preferable to SLAAC, =
so this may not be a huge issue, but worth considering in this section's re=
commendations, especially if 7.4 is now in a separate document.

Thanks
Wes George



________________________________
This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

--_000_34E4F50CAFA10349A41E0756550084FB0C494F3FPRVPEXVS04corpt_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 <=
/p>





From: ipv6-bou=
nces@ietf.org [mailto:ipv6-bounces@ietf.org]
On Behalf Of Joel Jaeggli

Sent: Sunday, August 07, 2011 1:58 PM

To: ipv6@ietf.org

Subject: Questions from the Authors of draft-gashinsky-v6nd-enhance<=
o:p>








 






1.     
Is this document (draft-gashinsky-v6nd-enhance) wor=
thwhile?


WEG] Yes






 






2. Is there critique of the two proposed 4861 change=
s?






 <=
/p>





 






   &nb=
sp;        B. 7.4 =
ND cache priming and refresh


WEG] might be worth think=
ing about situations where DHCPv6 is in use and whether that can be leverag=
ed to achieve something similar to this, i.e. watch the
 DHCPv6 messages go past and pre-populate the ND cache accordingly. 






 






2.     
Should we separate the potential mitigations (secti=
on 6) and implementation advice (section 7.1 and 7.2) into a separate docum=
ent.


WEG] yes. I thi=
nk that there’s value in getting the explanation and short-term mitig=
ation techniques out there sooner rather than later, and then if there is c=
onsensus that there is protocol work to be
 done to further mitigate the issue because the workarounds and tweaks disc=
ussed aren’t enough on their own, the workarounds and discussion of t=
he security issue aren’t being delayed by that protocol work.







 






   &nb=
sp;        A. Assumption (validat=
ed in v6ops at ietf81) is that v6ops would be happy






   &nb=
sp;         to take the miti=
gation and implementation advice as an informational document





 






   &nb=
sp;        B. Assumption 2 a draf=
t updating 4861 would be a standards track document.






 






   &nb=
sp;        C. Assumption 3, shoul=
d harmonize with  draft-nordmark-6man-impatient-nud-00<=
/p>

WEG] Agree with all 3 ass=
umptions.



Also, a comment on 7.1 &#=
8211; I think that this is roughly the right priority for certain applicati=
ons, but not necessarily for all cases. In networks where it is
 more common for devices to be coming and going frequently, it may not be a=
s appropriate to deprioritize traffic to unknown addresses. It may be that =
in a lot of those applications, DHCPv6 will be preferable to SLAAC, so this=
 may not be a huge issue, but worth
 considering in this section’s recommendations, especially if 7.4 is =
now in a separate document.


 <=
/p>

Thanks<=
/p>

Wes George







 






 









This E-mail and any of its a=
ttachments may contain Time Warner Cable proprietary information, which is =
privileged, confidential, or subject to copyright belonging to Time Warner =
Cable. This E-mail is intended solely
 for the use of the individual or entity to which it is addressed. If you a=
re not the intended recipient of this E-mail, you are hereby notified that =
any dissemination, distribution, copying, or action taken in relation to th=
e contents of and attachments to
 this E-mail is strictly prohibited and may be unlawful. If you have receiv=
ed this E-mail in error, please notify the sender immediately and permanent=
ly delete the original and any copy of this E-mail and any printout.





--_000_34E4F50CAFA10349A41E0756550084FB0C494F3FPRVPEXVS04corpt_--

From fred@cisco.com  Thu Aug 18 14:12:43 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700ED21F8AD6 for ; Thu, 18 Aug 2011 14:12:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.824
X-Spam-Level: 
X-Spam-Status: No, score=-102.824 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-8qbDx6yPu8 for ; Thu, 18 Aug 2011 14:12:42 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C45C721F8AD2 for ; Thu, 18 Aug 2011 14:12:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3052; q=dns/txt; s=iport; t=1313702018; x=1314911618; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=DLkPL8JzyeDlNUhMWsO5qMBpNzn+0yl8rSIUY/iD85k=; b=YOyT8AyeMXdHPnkhDzMr74YPUKYl6HnIhi7SNtYYdwGTtoY4dFlm7kLO JijW2mS0nKwzif4GA0tPmASppS5cvx3StjWmTvBxx7/RV8pLlzDgC87W5 PDtveizMKl4aRQ17WnFmH/FgkiKi4G8EAOLhQk4vz9XhAZl5tTmcNhNk+ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuEFAJJ/TU6rRDoH/2dsb2JhbABCgk2EaJgxAYgQd4FAAQEBAQIBEgFmBQsLBEJXBjWHTwSYOAGfE4VpXwSHYIszhQyMCQ
X-IronPort-AV: E=Sophos;i="4.68,247,1312156800"; d="scan'208,217";a="14475598"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 18 Aug 2011 21:13:37 +0000
Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7ILDWwr026062; Thu, 18 Aug 2011 21:13:33 GMT
Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Thu, 18 Aug 2011 14:13:35 -0700
X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Thu, 18 Aug 2011 14:13:35 -0700
Subject: Re: Questions from the Authors of draft-gashinsky-v6nd-enhance
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0C494F3F@PRVPEXVS04.corp.twcable.com>
Date: Thu, 18 Aug 2011 14:13:18 -0700
Message-Id: 
References: <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com> <34E4F50CAFA10349A41E0756550084FB0C494F3F@PRVPEXVS04.corp.twcable.com>
To: "George, Wesley" 
X-Mailer: Apple Mail (2.1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-170-387349148
Cc: "ipv6@ietf.org" 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 21:12:43 -0000

--Apple-Mail-170-387349148
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Aug 18, 2011, at 12:43 PM, George, Wesley wrote:

>             B. 7.4 ND cache priming and refresh
> WEG] might be worth thinking about situations where DHCPv6 is in use =
and whether that can be leveraged to achieve something similar to this, =
i.e. watch the DHCPv6 messages go past and pre-populate the ND cache =
accordingly.

If they go through your device, that makes sense. =
http://tools.ietf.org/html/draft-ietf-savi-dhcp would be an example. Any =
LAN that has two routers has a problem, though, as only one of them is =
likely to be/see the unicast DHCP responses.=

--Apple-Mail-170-387349148
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


        &=
nbsp;   B. 7.4 WEG] might be worth thinking =
about situations where DHCPv6 is in use and whether that can be =
leveraged to achieve something similar to this, i.e. watch the DHCPv6 =
messages go past and pre-populate the ND cache =
accordingly.

If they go =
through your device, that makes sense. http://tools.ietf=
.org/html/draft-ietf-savi-dhcp would be an example. Any LAN that has =
two routers has a problem, though, as only one of them is likely to =
be/see the unicast DHCP responses.=

--Apple-Mail-170-387349148--

From jhw@apple.com  Thu Aug 18 15:51:46 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897F921F8AF8 for ; Thu, 18 Aug 2011 15:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.642
X-Spam-Level: 
X-Spam-Status: No, score=-106.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUOZo29li0h0 for ; Thu, 18 Aug 2011 15:51:43 -0700 (PDT)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7194411E80A5 for ; Thu, 18 Aug 2011 15:51:43 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LQ5001P0BFDBY92@mail-out.apple.com> for ipv6@ietf.org; Thu, 18 Aug 2011 15:52:37 -0700 (PDT)
X-AuditID: 11807130-b7c45ae000001381-cd-4e4d9741fd57
Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate)	by relay11.apple.com (Apple SCV relay) with SMTP id 60.EA.04993.2479D4E4; Thu, 18 Aug 2011 15:50:42 -0700 (PDT)
Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) by kencur.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LQ500F7KBJOIC80@kencur.apple.com> for ipv6@ietf.org; Thu, 18 Aug 2011 15:52:37 -0700 (PDT)
Subject: Re: Questions from the Authors of draft-gashinsky-v6nd-enhance
From: james woodyatt 
In-reply-to: <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com>
Date: Thu, 18 Aug 2011 15:52:36 -0700
Message-id: <27E689EC-5540-47A7-8F80-36CF83C867CA@apple.com>
References: <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com>
To: Joel Jaeggli 
X-Mailer: Apple Mail (2.1244.3)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiON1OTddpuq+fwYaH7BYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvuLB0wFWxUqzmzcx9TA+Fyyi5GTQ0LAROLT4UNsELaYxIV7 64FsLg4hgXYmiSP/77KDJHgFBCV+TL7H0sXIwcEsIC9x8LwsSJhZQEvi+6NWFoj6JUwSS3dN YAFJCAu4S9z98pYJxGYTUJH4dvkumM0pYCux7flLVhCbRUBVYtuqi8wQgwQlrs6cxggyn1fA RmLywXiQsBCQefFLN9hIEQFliVNL5rNC3CkvsbjlM+MERoFZSK6bhXDdLCTXLWBkXsUoWJSa k1hpaKiXWFCQk6qXnJ+7iREUdg2FBjsY1/7kP8QowMGoxMP7UcPXT4g1say4MvcQowQHs5II r48BUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvhvfefkIC6YklqdmpqQWpRTBZJg5OqQbGxMs+ Vz5/MTmx2m2b6zPHOx90Sxyvb/hzJ1vhQ6dnQvwSj4e1GfF7dkpcWRfnqC/osSZ++x3xywJ+ F1q4kmY7Pu9nYd/kcE45t87l4PT8jtrHk1+Vlsyf4nmH12TbRq2rWhd4LqZzV5YxJaaLrXuv pxFfp3okc3fWCZaTy6eEF3k1xglPdc1RYinOSDTUYi4qTgQAxh2GdDcCAAA=
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 22:51:46 -0000

On Aug 7, 2011, at 10:57 , Joel Jaeggli wrote:
> 
> 2. Is there critique of the two proposed 4861 changes?
> 
> 	A. 7.3 NDP Protocol Gratuitous NA
> 	B. 7.4 ND cache priming and refresh

In the 6MAN session at IETF 81, I got up at the microphone and muttered some dark things about network sleep proxies. I should expand on those comments here on the list.

p1. Section 7.3 in the current draft deploys normative language thusly:

>>                                     [...] If the link layer address in
>>    an unsolicited neighbor advertisement matches that of the existing ND
>>    cache entry, routers SHOULD retain the existing entry updating it's
>>    status with regards to LRU retention policy. [...]

When a network sleep proxy accepts a new host registration, it will send a neighbor advertisement with a new and different source link-layer address, so routers that do this shouldn't have any trouble in the presence of network sleep proxies.

The next paragraph is marginally more interesting for its network sleep proxy considerations:

>>    Hosts MAY be configured to send unsolicited Neighbor advertisement at
>>    a rate set at the discretion of the operators.  The rate SHOULD be
>>    appropriate to the sizing of ND cache parameters and the host count
>>    on the subnet.  An unsolicited NA rate parameter MUST NOT be enabled
>>    by default.  The unsolicted rate interval as interpreted by hosts
>>    must jitter the value for the interval between transmissions.  Hosts
>>    receiving a neighbor solicitation requests from a router following
>>    each of three subsequent gratuitous NA intervals MUST revert to RFC
>>    4861 behavior.

Network sleep proxies are a subtype of hosts.  One imagines that a network sleep proxy might be configured to send unsolicited Neighbor Advertisements messages on behalf of sleeping hosts, which may or may not be configured differently than their proxy.  Moreover, network sleep proxies may themselves go to sleep, and transfer their registrations to another proxy.  Different proxies may or may not be configured the same way.

All this makes me wonder just how a host SHOULD be configured with its unsolicited neighbor advertisement rate.  Do we imagine defining a Router Advertisement option?  That's my preferred solution, because it would be useful even in the case where both M=0 and O=0.  It is, after all, a network configuration parameter and not really a host configuration parameter.  If we choose a Router Advertisement option, then we have to think about how to merge the advertisements from multiple default routers.

p2. Section 7.4 in the current draft has this to say:

>>    A solution to this would be that any new host that joins the network
>>    would "announce" itself, and be added to the cache, therefore not
>>    requiring packets destined to it to go through the unknown NDP queue.
>>    This could be done by sending a ping packet to the all-routers
>>    multicast address, which would then trigger the router's own neighbor
>>    resolution process, which should be in a different queue then other
>>    packets.

These echo requests will also be sent by network sleep proxies when they accept new registrations from existing hosts (including other sleep proxies) when they enter a sleeping mode.  It's probably worth noting that it isn't a good idea for a sleep proxy to send the echo requests *before* sending the unsolicited neighbor advertisement with the new link-layer address.  However, if the router under attack correctly processes the unsolicited neighbor advertisement, then the echo request should prime the neighbor cache in the router with the link-layer address of the sleep proxy.

Routers serving networks comprising lots of sleeping hosts and one or more network sleep proxies will be receiving a lot of echo requests from a small number of link-layer addresses, i.e. the sleep proxies, as hosts enter and leave sleeping mode.  It seems like there should be an opportunity to optimize on that.


--
james woodyatt 
member of technical staff, core os networking




From nordmark@acm.org  Thu Aug 18 16:03:19 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D97E21F8A23 for ; Thu, 18 Aug 2011 16:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.127
X-Spam-Level: 
X-Spam-Status: No, score=-103.127 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O81HdkFErUaW for ; Thu, 18 Aug 2011 16:03:18 -0700 (PDT)
Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 8E45121F871E for ; Thu, 18 Aug 2011 16:03:18 -0700 (PDT)
Received: from [10.33.22.81] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p7IN49B1027319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Aug 2011 16:04:09 -0700
Message-ID: <4E4D9A68.3060201@acm.org>
Date: Thu, 18 Aug 2011 16:04:08 -0700
From: Erik Nordmark 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: james woodyatt 
Subject: Re: Questions from the Authors of draft-gashinsky-v6nd-enhance
References: <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com> <27E689EC-5540-47A7-8F80-36CF83C867CA@apple.com>
In-Reply-To: <27E689EC-5540-47A7-8F80-36CF83C867CA@apple.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 23:03:19 -0000

On 8/18/11 3:52 PM, james woodyatt wrote:
> Network sleep proxies are a subtype of hosts.  One imagines that a network sleep proxy might be configured to send unsolicited Neighbor Advertisements messages on behalf of sleeping hosts, which may or may not be configured differently than their proxy.  Moreover, network sleep proxies may themselves go to sleep, and transfer their registrations to another proxy.  Different proxies may or may not be configured the same way.

James,

How would such sleep proxies interact with SeND?

I think if we want to support a form of registration of hosts (whether 
they are sleeping or not) it might be simplest to adopt the Address 
Registration option in draft-ietf-6lowpan-nd for wider use than 6lowpans.

My 2 cents,

    Erik


From jhw@apple.com  Thu Aug 18 16:48:23 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD4721F881C for ; Thu, 18 Aug 2011 16:48:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.641
X-Spam-Level: 
X-Spam-Status: No, score=-106.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtP4C67le17f for ; Thu, 18 Aug 2011 16:48:23 -0700 (PDT)
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id F1F7021F880C for ; Thu, 18 Aug 2011 16:48:22 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LQ500ESHE5TMT00@mail-out.apple.com> for ipv6@ietf.org; Thu, 18 Aug 2011 16:49:17 -0700 (PDT)
X-AuditID: 11807134-b7c71ae0000014d0-66-4e4da37b7df6
Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate)	by relay14.apple.com (Apple SCV relay) with SMTP id 2E.87.05328.B73AD4E4; Thu, 18 Aug 2011 16:42:51 -0700 (PDT)
Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LQ500LFRE64FY80@koseret.apple.com> for ipv6@ietf.org; Thu, 18 Aug 2011 16:49:16 -0700 (PDT)
Subject: Re: Questions from the Authors of draft-gashinsky-v6nd-enhance
From: james woodyatt 
In-reply-to: <4E4D9A68.3060201@acm.org>
Date: Thu, 18 Aug 2011 16:49:15 -0700
Message-id: <1EA08E76-1FD7-4F20-AD5C-42A89AA8BE60@apple.com>
References: <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com> <27E689EC-5540-47A7-8F80-36CF83C867CA@apple.com> <4E4D9A68.3060201@acm.org>
To: Erik Nordmark 
X-Mailer: Apple Mail (2.1244.3)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUiON1OXbd6sa+fwaaFehYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsOSv2wFx7grpv69wNrAuJqzi5GTQ0LARKLn8yJmCFtM4sK9 9WxdjFwcQgKdTBJT5z9mAUnwCghK/Jh8D8jm4GAWkJc4eF4WJMwsoCXx/VErWImQwDImiXvf weLCAu4Sd7+8ZQKx2QRUJL5dvgtmcwqoSyx72s8IYrMIqEos3/yPEWKOkcSjrVtYIVbZSCy4 9pYZYmYXo8SrZdEgtgjQnBkXLzFC3CkvsbjlM+MERoFZSK6bhXDdLCTXLWBkXsUoWJSak1hp aKKXWFCQk6qXnJ+7iREUdg2FJjsYD/7kP8QowMGoxMM7U83XT4g1say4MvcQowQHs5IIr48B UIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv1CyglEB6YklqdmpqQWoRTJaJg1OqgTEhTULxbubD EwJOn3d2c4idennR8Ab/ddkNzUt/H1k991P2lDtpVtPjkzlXRihuy3aNNF2jvfrLKt69bSu0 bgu2b1m47cM3O/MdoVsyHq6uP5T+0j3kju33N7FKH22aBR/3t/a8PfmiJ9Mr0fX45IrZpye/ u8n+7VtNzsGUcL91XRIVP3ZEF7AqsRRnJBpqMRcVJwIA/uVIozcCAAA=
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 Aug 2011 23:48:23 -0000

On Aug 18, 2011, at 16:04 , Erik Nordmark wrote:
> 
> How would such sleep proxies interact with SeND?

Theoretically, not very securely.  This problem, if you ask me, is one of the major deficiencies in SEND.  It needs to be revised to support sleep proxies.  (It's not just network sleep proxies that have trouble with SEND.  So do host sleep proxies.)

What I mean by "theoretically" is that, at present, I am unaware of neither any sleep proxies that implement SEcure Neighbor Discovery [RFC 3971], nor any that employ a security protocol of any kind between the sleeping host and the sleep proxy to which it registers.  "Security is hard; let's go SHOPPING!"

In theory, assuming all hosts and their sleep proxies are using SEND (because non-SEND nodes are not admitted to the network, or at least they aren't trusted by any of the other nodes they find on the network), then sleep proxies will need to possess the RSA private keys for all the CGAs that their client hosts register with them, and when sleep proxies themselves go to sleep, they may need to transfer those credentials to the next sleep proxy in turn.

I suppose one might imagine improving SEND with express support for sleep proxies, but I'm guessing that the major users of SEND are people for whom the choice to trade energy efficiency for network security doesn't usually require very much thought.


--
james woodyatt 
member of technical staff, core os networking




From jhw@apple.com  Fri Aug 19 11:57:06 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4BA21F8AB0 for ; Fri, 19 Aug 2011 11:57:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW9eGkJ9lzVi for ; Fri, 19 Aug 2011 11:57:05 -0700 (PDT)
Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id C5E3821F8AAF for ; Fri, 19 Aug 2011 11:57:05 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LQ600EZOVCCMTN1@mail-out.apple.com> for ipv6@ietf.org; Fri, 19 Aug 2011 11:58:02 -0700 (PDT)
X-AuditID: 11807130-b7c45ae000001381-91-4e4eb1c51034
Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate)	by relay11.apple.com (Apple SCV relay) with SMTP id 60.65.04993.5C1BE4E4; Fri, 19 Aug 2011 11:56:05 -0700 (PDT)
Received: from [17.153.46.248] (unknown [17.153.46.248]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LQ600JHRVCQPF70@koseret.apple.com> for ipv6@ietf.org; Fri, 19 Aug 2011 11:58:02 -0700 (PDT)
Subject: Re: Questions from the Authors of draft-gashinsky-v6nd-enhance
From: james woodyatt 
In-reply-to: <1EA08E76-1FD7-4F20-AD5C-42A89AA8BE60@apple.com>
Date: Fri, 19 Aug 2011 11:58:04 -0700
Message-id: 
References: <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com> <27E689EC-5540-47A7-8F80-36CF83C867CA@apple.com> <4E4D9A68.3060201@acm.org> <1EA08E76-1FD7-4F20-AD5C-42A89AA8BE60@apple.com>
To: 6MAN 
X-Mailer: Apple Mail (2.1244.3)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUiON1OXffoRj8/g5Z9RhYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRs+9vWwF/zgqVtxcy97AuIC9i5GTQ0LARGLjiSVQtpjEhXvr 2boYuTiEBDqZJB5d+cUCkuAVEJT4MfkekM3BwSwgL3HwvCxImFlAS+L7o1YWiPqZTBLL/21k AkkIC7hL3P3yFsxmE1CR+Hb5LpjNKWArMf38GrBlLAKqEsfaW9gh5ttIXF1/nhFi0F5GiZPH v4AtFhGQkPh87zDUdfISi1s+M05g5J+F5KZZCDfNQnLTAkbmVYyCRak5iZWGhnqJBQU5qXrJ +bmbGEEh1lBosINx7U/+Q4wCHIxKPLyGvX5+QqyJZcWVuYcYJTiYlUR4WyOAQrwpiZVVqUX5 8UWlOanFhxilOViUxHkDD/j6CQmkJ5akZqemFqQWwWSZODilGhhPFhzacsqhbMPbBc73Xn6u XHilNCPE4+sV029TNRpnWbULPrMrc8l14mqP3r1lm33WnA+Jr45x3L/drn5/8cW7K21W/7+6 0z1mPr8Fz73K0MN+nIvZ1psHdwTxnDRZsu4pv6jG7KisomPadoVLFZ55d928bviLYwJr8b/P d9MipHgVAoXWZUcqsRRnJBpqMRcVJwIAqNPgsS0CAAA=
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 18:57:06 -0000

On Aug 18, 2011, at 4:49 PM, james woodyatt wrote:
> 
> ...then sleep proxies will need to possess the RSA private keys for all the CGAs that their client hosts register with them...

Correction: I think SEND as it is currently constituted actually just breaks sleep proxies entirely.  A cryptographically generated address is one-way function of the link-local address, and I'm pretty sure that sleep proxies shouldn't be sending source link-layer address options in neighbor discovery packets that don't match their own source hardware address.

And besides, if they did that to make SEND work, you'd still be going against section 9.1, which says:

   Even on a secured link layer, SEND does not require that the
   addresses on the link layer and Neighbor Advertisements correspond.
   However, performing these checks is RECOMMENDED if the link layer
   technology permits.

Really, I think SEND is basically incompatible with sleep proxies, which is the main reason I'm not in a big hurry to recommend implementing it in Apple products.


--
james woodyatt 
member of technical staff, core os networking




From warren@kumari.net  Fri Aug 19 12:39:55 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6712E21F8B1D for ; Fri, 19 Aug 2011 12:39:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.126
X-Spam-Level: 
X-Spam-Status: No, score=-102.126 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIhbyzqz8loR for ; Fri, 19 Aug 2011 12:39:54 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id BA07821F86EE for ; Fri, 19 Aug 2011 12:39:54 -0700 (PDT)
Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id DCD071B416D9; Fri, 19 Aug 2011 15:40:50 -0400 (EDT)
Subject: Re: Questions from the Authors of draft-gashinsky-v6nd-enhance
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Warren Kumari 
In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0C494F3F@PRVPEXVS04.corp.twcable.com>
Date: Fri, 19 Aug 2011 15:40:49 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com> <34E4F50CAFA10349A41E0756550084FB0C494F3F@PRVPEXVS04.corp.twcable.com>
To: "George, Wesley" 
X-Mailer: Apple Mail (2.1084)
Cc: "ipv6@ietf.org" 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2011 19:39:55 -0000

On Aug 18, 2011, at 3:43 PM, George, Wesley wrote:

> =20
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf =
Of Joel Jaeggli
> Sent: Sunday, August 07, 2011 1:58 PM
> To: ipv6@ietf.org
> Subject: Questions from the Authors of draft-gashinsky-v6nd-enhance
> =20
> 1.      Is this document (draft-gashinsky-v6nd-enhance) worthwhile?
> WEG] Yes
> =20
> 2. Is there critique of the two proposed 4861 changes?
> =20
> =20
>             B. 7.4 ND cache priming and refresh
> WEG] might be worth thinking about situations where DHCPv6 is in use =
and whether that can be leveraged to achieve something similar to this, =
i.e. watch the DHCPv6 messages go past and pre-populate the ND cache =
accordingly.

Wow.=20

I hadn't though of that, but seeing as a bunch of things already snoop / =
relay DHCP, this seems clever...

W

> =20
> 2.      Should we separate the potential mitigations (section 6) and =
implementation advice (section 7.1 and 7.2) into a separate document.
> WEG] yes. I think that there=92s value in getting the explanation and =
short-term mitigation techniques out there sooner rather than later, and =
then if there is consensus that there is protocol work to be done to =
further mitigate the issue because the workarounds and tweaks discussed =
aren=92t enough on their own, the workarounds and discussion of the =
security issue aren=92t being delayed by that protocol work.
> =20
>             A. Assumption (validated in v6ops at ietf81) is that v6ops =
would be happy
>              to take the mitigation and implementation advice as an =
informational document
> =20
>             B. Assumption 2 a draft updating 4861 would be a standards =
track document.
> =20
>             C. Assumption 3, should harmonize with  =
draft-nordmark-6man-impatient-nud-00
> WEG] Agree with all 3 assumptions.
> Also, a comment on 7.1 =96 I think that this is roughly the right =
priority for certain applications, but not necessarily for all cases. In =
networks where it is more common for devices to be coming and going =
frequently, it may not be as appropriate to deprioritize traffic to =
unknown addresses. It may be that in a lot of those applications, DHCPv6 =
will be preferable to SLAAC, so this may not be a huge issue, but worth =
considering in this section=92s recommendations, especially if 7.4 is =
now in a separate document.
> =20
> Thanks
> Wes George
> =20
> =20
>=20
> This E-mail and any of its attachments may contain Time Warner Cable =
proprietary information, which is privileged, confidential, or subject =
to copyright belonging to Time Warner Cable. This E-mail is intended =
solely for the use of the individual or entity to which it is addressed. =
If you are not the intended recipient of this E-mail, you are hereby =
notified that any dissemination, distribution, copying, or action taken =
in relation to the contents of and attachments to this E-mail is =
strictly prohibited and may be unlawful. If you have received this =
E-mail in error, please notify the sender immediately and permanently =
delete the original and any copy of this E-mail and any printout.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From joelja@bogus.com  Wed Aug 24 09:19:19 2011
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B8221F8C76 for ; Wed, 24 Aug 2011 09:19:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.358
X-Spam-Level: 
X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tP68jQhsM3S for ; Wed, 24 Aug 2011 09:19:19 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 454A621F8C75 for ; Wed, 24 Aug 2011 09:19:19 -0700 (PDT)
Received: from [10.101.144.54] (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p7OGKSjf071912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 24 Aug 2011 16:20:29 GMT (envelope-from joelja@bogus.com)
Subject: Re: Questions from the Authors of draft-gashinsky-v6nd-enhance
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-17-888174895
From: Joel Jaeggli 
In-Reply-To: 
Date: Wed, 24 Aug 2011 09:20:23 -0700
Message-Id: <117F5E26-FE18-4F9A-83E7-6FCAB7BFEF63@bogus.com>
References: <4CF32C15-36D0-4287-8573-ABF750F8BB08@bogus.com> <34E4F50CAFA10349A41E0756550084FB0C494F3F@PRVPEXVS04.corp.twcable.com> 
To: Fred Baker 
X-Mailer: Apple Mail (2.1084)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 24 Aug 2011 16:20:29 +0000 (UTC)
Cc: "ipv6@ietf.org" 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2011 16:19:20 -0000

--Apple-Mail-17-888174895
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Aug 18, 2011, at 2:13 PM, Fred Baker wrote:

>=20
> On Aug 18, 2011, at 12:43 PM, George, Wesley wrote:
>=20
>>             B. 7.4 ND cache priming and refresh
>> WEG] might be worth thinking about situations where DHCPv6 is in use =
and whether that can be leveraged to achieve something similar to this, =
i.e. watch the DHCPv6 messages go past and pre-populate the ND cache =
accordingly.
>=20
> If they go through your device, that makes sense. =
http://tools.ietf.org/html/draft-ietf-savi-dhcp would be an example. Any =
LAN that has two routers has a problem, though, as only one of them is =
likely to be/see the unicast DHCP responses.

Also I mostly thought about this in the reverse context, e.g. a large =
number of hosts keeping the router's address in their cache.

it is possible to that this scenario is in fact invalid, which would =
make the draft simpler.


--Apple-Mail-17-888174895
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On Aug 18, 2011, =
at 12:43 PM, George, Wesley wrote:

        &=
nbsp;   B. 7.4 WEG] might be worth thinking =
about situations where DHCPv6 is in use and whether that can be =
leveraged to achieve something similar to this, i.e. watch the DHCPv6 =
messages go past and pre-populate the ND cache =
accordingly.

If they go =
through your device, that makes sense. http://tools.ietf=
.org/html/draft-ietf-savi-dhcp would be an example. Any LAN that has =
two routers has a problem, though, as only one of them is likely to =
be/see the unicast DHCP responses.

Also =
I mostly thought about this in the reverse context, e.g. a large number =
of hosts keeping the router's address in their =
cache.

it is possible to that this scenario is =
in fact invalid, which would make the draft =
simpler.

=

--Apple-Mail-17-888174895--