From Internet-Drafts@ietf.org Mon May 2 14:15: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 207EFE0780; Mon, 2 May 2011 14:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 C67Q3yz2t1nI; Mon, 2 May 2011 14:15:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6790BE076F; Mon, 2 May 2011 14:15:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-6man-flow-update-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110502211504.27541.69611.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2011 14:15:04 -0700 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, 02 May 2011 21:15:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Rationale for update to the IPv6 flow label specification Author(s) : S. Amante, et al. Filename : draft-ietf-6man-flow-update-05.txt Pages : 13 Date : 2011-05-02 Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it, and to introduce some additional flexibility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-6man-flow-update-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-02140429.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon May 2 14:15: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 610AFE0772; Mon, 2 May 2011 14:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 juHPTRlD2i5A; Mon, 2 May 2011 14:15:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C8CE0773; Mon, 2 May 2011 14:15:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-6man-flow-3697bis-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110502211504.27541.72957.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2011 14:15:04 -0700 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, 02 May 2011 21:15:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : IPv6 Flow Label Specification Author(s) : S. Amante, et al. Filename : draft-ietf-6man-flow-3697bis-03.txt Pages : 14 Date : 2011-05-02 This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-6man-flow-3697bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-02140452.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon May 2 14:15:07 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 1AC21E0782; Mon, 2 May 2011 14:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 VXa0q+nOixSZ; Mon, 2 May 2011 14:15:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89669E0775; Mon, 2 May 2011 14:15:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-6man-flow-ecmp-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110502211504.27541.57912.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2011 14:15:04 -0700 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, 02 May 2011 21:15:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels Author(s) : B. Carpenter, S. Amante Filename : draft-ietf-6man-flow-ecmp-02.txt Pages : 10 Date : 2011-05-02 The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-ecmp-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-6man-flow-ecmp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-02140512.I-D@ietf.org> --NextPart-- From brian.e.carpenter@gmail.com Mon May 2 14:24:24 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 420AFE07AC for ; Mon, 2 May 2011 14:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 GhrdFBmh6+W6 for ; Mon, 2 May 2011 14:24:23 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 931C4E0776 for ; Mon, 2 May 2011 14:24:13 -0700 (PDT) Received: by pvh1 with SMTP id 1so4185276pvh.31 for ; Mon, 02 May 2011 14:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ff3dZlvuecXPxqYPxCAwG3+YxRwMrSqmQLXFzmELCuQ=; b=jcbft5RydYcdXTw3Idcf5FU3TJWEhj7r0WSoWM+6htlJIwR57/ccqXrIrVR6FgiLje h4t60q+l9QvfV3Me6q3TUBM7Uw47jUl2tG5cimswcZz0sVmiU1ppkAZTQ/kuJHbziUZo 6+BreZZUm4vIvdwG3ctl95Q6JoejgnZSogkZU= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Bg7J5nrn9VfN7EEmY+wwKt2Y2kdDwYFkvfvOXEGKXTWhRMGpaYTTGzqqL9xrBFtT4O ODvTtdMsdx6Xvg9Xa5mkI99Bwe4bWCwLuDjhq1wqOwsvcPJ+XNJtWyKMoVzvac+D6N82 2hy0QVHVBVpQbw3uEVv3ZdidFXrcaQiTJa5DA= Received: by 10.68.24.97 with SMTP id t1mr9084419pbf.329.1304371453338; Mon, 02 May 2011 14:24:13 -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 f3sm4015599pbq.58.2011.05.02.14.24.10 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 14:24:12 -0700 (PDT) Message-ID: <4DBF20F9.3080403@gmail.com> Date: Tue, 03 May 2011 09:24:09 +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: Flow label drafts updated References: <4D77DBD8.4090800@innovationslab.net> <4D792360.5@gmail.com> <4D7A2995.9090204@innovationslab.net> <5D36713D8A4E7348A7E10DF7437A4B927FCAE2@SZXEML504-MBX.china.huawei.com> <4DB8C07B.8060004@gmail.com> <1B02010E-CE2C-45D7-938E-6FFED7721752@castlepoint.net> <4DBB1997.8030709@gmail.com> <4DBB2618.3070705@gmail.com> <3769FB5A-DACF-48B0-BB43-06D0669D6D1E@castlepoint.net> <4DBE1718.2080104@gmail.com> In-Reply-To: <4DBE1718.2080104@gmail.com> Content-Type: text/plain; charset=UTF-8 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: Mon, 02 May 2011 21:24:24 -0000 Hi, All three flow label drafts have now been updated. They can be found conveniently at https://datatracker.ietf.org/doc/search/?name=draft-ietf-6man-flow&activeDrafts=on I will shortly send messages explaining how we've dealt with the final set of WGLC comments. Regards Brian + co-authors From brian.e.carpenter@gmail.com Mon May 2 14:34: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 9A213E07C3 for ; Mon, 2 May 2011 14:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.45 X-Spam-Level: X-Spam-Status: No, score=-103.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 8wySmWbhBHcl for ; Mon, 2 May 2011 14:34:31 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B813E07BE for ; Mon, 2 May 2011 14:34:31 -0700 (PDT) Received: by pvh1 with SMTP id 1so4189289pvh.31 for ; Mon, 02 May 2011 14:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OrFL2Eyg9/E4rGqA3PYkCGHunR3UWU24Y8l3FBZRRCo=; b=A5qsRkzjLrBUeAq9U6pfbkmsmszduAkmtDQF0FiLAWupJKM4SIOc0eOarNrXXsfsls ePoNbfeqPpyESxdRz6IJdCZgmubxFUD9m0tyOO4qxWZCY1wX1dt7EeBBgx/CQxzgzHC1 obNU7vMY510ICQ5SVTKdaDk7Sub2Olt+0kfGg= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=iXJy15X8GVhxY9ip4orSAuC8ewwAGgrIS2kRgjde74BpLr2e9Ux1OE3vnYF5YJtG30 NYHn1nWCTD5a9V2qdbaAPNuZmcNnpVTk0mPggHdtNt6/et5zmWb5JzY/yeD8mxbI5j1J iHtfD76ZlOFgaB9gEnu7z0u/d18a8SbxndH0s= Received: by 10.68.30.137 with SMTP id s9mr8606309pbh.146.1304372071322; Mon, 02 May 2011 14:34:31 -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 y7sm4049472pbk.30.2011.05.02.14.34.28 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 14:34:30 -0700 (PDT) Message-ID: <4DBF2362.8040600@gmail.com> Date: Tue, 03 May 2011 09:34:26 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten , 6man Subject: Re: 6MAN WG Last Call: References: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> In-Reply-To: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 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: Mon, 02 May 2011 21:34:32 -0000 On 2011-04-06 05:40, Thomas Narten wrote: > Here are my detailed comments on the document. I did chat with Brian > directly in Prague about these points as well. Overall, I support this > document. But I think the wording in places needs another round of > revision. > > A flow is a sequence of packets sent from a particular source to a > particular unicast, anycast, or multicast destination that a node > desires to label as a flow. A flow could consist of all packets in a > > This is a circular definition. Somewhat intentionally: a flow is whatever the source chooses to label as a flow. We'll take Bob's reply as cancelling your comment out, except for a small clarification in the text. > I think it would be useful to give two > definitions, something like the following: > > A Flow is a sequence of packets originating from a particular > application that should be treated "the same" by the network as > they are forwarded along to their ultimate destination. Packets > within a flow should not be reordered, should not be given > dissimilar QOS treatment, etc. What constitutes a Flow can only be > defined by the application itself. > > At the network level, routers need to be able to identify packets > belonging to the same Flow in order to process them > consistently. At the same time, it may be beneficial to process > packets between the same src/destination pairs (but from different > application flows) differently, e.g., to support ECMP or other > types of load splitting. > > Then: > > Traditionally, flow classifiers have been based on the 5-tuple of the > source and destination addresses, ports, and the transport > protocol > > add "flow classifiers at the network layer" Well, using the transport information makes it a layer violation. Do we really want to open that discussion? > > The 20-bit Flow Label field in the IPv6 header [RFC2460] is used by a > node to label packets of a flow. A Flow Label of zero is used to > indicate packets not part of any flow. Packet classifiers can use > > reword to say "that have not been labeled" (Packets will almost always > be part of some Flow). OK > > specification. However, any node that sets flow label values > according to a stateful scheme MUST ensure that packets conform to > Section 3 of the present specification if they are sent outside the > network domain using the stateful scheme. > > The above wording regarding "sent outside the network domain" is > problematic. It hints that maybe you can do things with the Flow Label > within a domain so long as you don't send such packets outside the > domain. We shouldn't even hint that that is acceptable. I'd suggest > removing all references to the "stateful" flow label scheme to one > section. And that section could be very short. We agree that this all belongs together in one short paragraph (see below). But we don't agree to remove the "MUST ensure...". We believe this is a mandatory constraint on all hypothetical stateful schemes. > > 1. Implementers are advised that forwarding nodes, especially those > acting as domain border devices, might nevertheless be configured > to change the flow label value in packets. This is undetectable, > unless some future version of IPsec authentication [RFC4302] > protects the flow label value. > > Remove this. Again, the Flow Label is not allowed to be modified > accept when zero. That is all that needs to be said. We've been assured several times that firewalls will do this. However, we think this belongs in the security considerations. The phrase about IPsec also needed rephrasing - as you pointed out in Prague, there is no likelihood of a future version of IPsec authentication. > > if the packet will leave their domain. If it is known to a > border router that flow labels originated within the domain are > not uniformly distributed, it will need to set outgoing flow > labels in the same manner as described for forwarding nodes in > Section 3. > > Remove this. It agains suggests border routers will be resetting Flow > Label values. In fact we took the whole paragraph out, but retained some of it in the rationale document in a different form. We certainly don't want to enourage this. > > o Implementers should be aware that the flow label is an unprotected > field that could have been accidentally or intentionally changed > en route. Implementations MUST take appropriate steps to protect > themselves from being vulnerable to denial of service and other > types of attack that could result (see Section 6.1). > > Can we just move this advice to the Security Considerations section? > IMO, we are giving it too much weight by having it in the main text. OK > > o Forwarding nodes such as routers and load balancers MUST NOT > depend only on Flow Label values being uniformly distributed. In > any usage such as a hash key for load distribution, the Flow Label > bits MUST be combined at least with bits from other sources within > the packet, so as to produce a constant hash value for each flow > and a suitable distribution of hash values across flows. > > > Can't we just come out and say that routers should: > > 1) use the src/dest/flow/port numbers? this is the most prefered. > > 2) if you can't use the port numbers, hash on the 3 tuple. > > 3) you could also say hash on teh src/dest alone as a last resort, but > why the Flow Label RFC would suggest that isn't immediately obvious to > me. :-) Indeed. We added a succinct version of the above (referring to the 5-tuple). > > The use of the Flow Label field does not necessarily signal any > requirement on packet reordering. Especially, the zero label does > not imply that significant reordering is acceptable. > > The first sentence above isn't right. One SHOULD NOT reorder packets > from the same flow. Period. Agreed, rewritten. > > An IPv6 node that does not set the flow label to a non-zero value, or > make use of it in any way, MUST ignore it when receiving or > forwarding a packet. > > I don't understand why this wording is in here. For the stateless > case, nodes should simply ignore the received Flow Label value. We > should probably just say that. We concluded that the sentence is a no-op and deleted it. > > It is desirable that flow label values should be uniformly > distributed to assist load distribution. It is therefore RECOMMENDED > that source hosts support the flow label by setting the flow label > field for all packets of a given flow to the same uniformly > distributed pseudo-random value. Both stateful and stateless methods > of assigning a pseudo-random value could be used, but it is outside > the scope of this specification to mandate an algorithm. In a > stateless mechanism, the algorithm SHOULD ensure that the resulting > flow label values are unique with high probability. > > I think we need to specify some recommended algorithms. They can be > SHOULDs (rather than MUST), but saying nothing leaves things too > unclear. In particular, if we think just doing a simple hash based on > the port numbers (or something) is good enough, we should recommend > that. We're reluctant to use a normative SHOULD in fact - in the end it's an implementation choice - but yes, we should give clear suggestions - see new text. > > Also, this document should not be requiring (or even use SHOULD) to > say pseudo randomness is necessary. This document has not made the > case for that. We need to be clearer that *variability* of the values is necessary. We've added unguessability as a requirement, which explains why sequential flow values are a bad idea. There are quite a lot of resulting text changes. In fact tidying this up (here and in the rationale document) led us to look into the formal definition, both in statistics texts and at: http://en.wikipedia.org/wiki/Discrete_uniform_distribution > > An OPTIONAL algorithm for generating such a pseudo-random value is > described in [I-D.gont-6man-flowlabel-security]. > > [[ NOTE TO RFC EDITOR: The preceding sentence should be deleted, and > the reference should be changed to Informative, if the cited draft is > not on the standards track at the time of publication. ]] > > I'd prefer that this document provide a suggested algorithm. The reference is gone anyway because that draft isn't moving. > > A source node which does not otherwise set the flow label MUST set > its value to zero. > > Better: just say that the default value should be zero, unless set > explicitely. Er, isn't that exactly what the sentence says? > > A node that forwards a flow whose flow label value in arriving > packets is zero MAY set the flow label value. In that case, it is > > s/MAY set/MAY change/ OK > A node that sets the flow label MAY also take part in a flow state > establishment method that results in assigning specific treatments to > specific flows, possibly including signaling. Any such method MUST > NOT disturb nodes taking part in the stateless model just described. > Further details are not discussed in this document. > > I don't understand what does this is really intended to mean. IMO, > just say the first sentence, and then say the details of stateful are > out of scope for this document. This is where we want to relocate the "MUST ensure..." sentence mentioned above. It means that stateful mechanisms mustn't mess up the stateless model, and we don't care and don't say how they achieve that. > > would cause a stateful mechanism to behave incorrectly. For this > reason, stateless mechanisms should not use the flow label alone to > control load distribution, and stateful mechanisms should include > > s/stateless mechanisms/stateless classifiers/ OK Brian, for the authors From brian.e.carpenter@gmail.com Mon May 2 14:37:59 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 296C3E07D9 for ; Mon, 2 May 2011 14:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.465 X-Spam-Level: X-Spam-Status: No, score=-103.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 UrD+drnrpH1g for ; Mon, 2 May 2011 14:37:58 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 72198E07D8 for ; Mon, 2 May 2011 14:37:58 -0700 (PDT) Received: by pzk5 with SMTP id 5so4000358pzk.31 for ; Mon, 02 May 2011 14:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UlgeDV42Iw/8trqSVhyv2HUpEtuNKn2+0aLHeIBl16A=; b=dt5BRwC/mRfDWWtrbT4xVL6sYOmlB2CDd21ZzmO6hn24CsB2qvYE2ULpahak4kkBoa hTytwAv9OKrzfXosFlTGrZNpRHxSi2Vl50CGfZtbf/XxTRmmoOYxvjtK3lbDhZNsMjw8 HkhTNfS/48dI2tMCOXG1cNW9Ydd2SB35RtPQc= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=vKY11zNHt4EuibPjV2XDOoT9HGnfTWyBgwp+/tvJF4Rw3FkztvJnW0MJqdV0Bttvg5 dSK4JZBzwZOa/CtNYCS3ytvxcrFIwHNeiztklASNfBmKphH0gIrz5eDG5jNbNkyhwqIq qsGAfy/tY/AEXoycyWsaMaJKW2w3JdMLTlwmw= Received: by 10.68.40.69 with SMTP id v5mr9284452pbk.467.1304372277766; Mon, 02 May 2011 14:37:57 -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 s7sm52247pbn.15.2011.05.02.14.37.55 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 14:37:57 -0700 (PDT) Message-ID: <4DBF2431.8000306@gmail.com> Date: Tue, 03 May 2011 09:37:53 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten , 6man Mailing List Subject: Re: 6MAN WG Last Call: References: <2F8FF78F-24CF-4895-A5BC-EA4167D92C6D@gmail.com> <201104051809.p35I94HL018340@cichlid.raleigh.ibm.com> In-Reply-To: <201104051809.p35I94HL018340@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 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: Mon, 02 May 2011 21:37:59 -0000 On 2011-04-06 06:09, Thomas Narten wrote: > Here are my comments on this document. > > My main issue is that it continues to assert that flow labels are > required to be pseudo random. I am not convinced that is necessary and > I think it makes things more complex than necessary. Emphasis changed to uniform distribution (and some text added why this is desirable). See comments on 3697bis. > Detailed comments: > > Review of -04 > > Also, it could be used as a covert data channel, since apparently > pseudo-random flow label values could in fact consist of covert data. > > drop "pseudo-random" as that is not relevant to the point. Oh yes it is ;-). If the bits are cyphertext encrypted with a good algorithm, as they would be in serious covert usage, they would indeed appear pseudo-random. If somebody included plaintext in the flow label, that would hardly be covert. > > As a result, some security > specialists believe that flow labels should be cleared for safety. > > If you don't have a reference to this, please delete. It's mentioned in draft-gont-6man-flowlabel-security. > > However, it is recommended that sources should set a pseudo-random > flow label value in all flows, replacing the less precise > recommendation made in Section 3 of RFC 3697. Both stateful and > > Again, I don't think we have agreement on this "recommendation". Ack, see above. > mathematically on immutable flow labels. The new rules require that > flow labels exported to the Internet should always be either zero or > pseudo-random, but even this cannot be relied on mathematically. Use > > Pseudo random requirement again... > Ditto. Brian, for the authors From brian.e.carpenter@gmail.com Mon May 2 14:39:47 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 EB1B0E06BD for ; Mon, 2 May 2011 14:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.471 X-Spam-Level: X-Spam-Status: No, score=-103.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 NVYcBRDtwaFw for ; Mon, 2 May 2011 14:39:47 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 261C7E0674 for ; Mon, 2 May 2011 14:39:47 -0700 (PDT) Received: by pwi5 with SMTP id 5so3586874pwi.31 for ; Mon, 02 May 2011 14:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0zjTh+4PVt2cOd1hwcOhRpaXTOtEM12YH4yednJbFzc=; b=vybteH3ckBeqEFPTgNNKJCwwxB+Zav915R86cfl+WamokS4T7M4B/ky1dY39V2d+La ny2h+lhr7w0L2CI+1uRQXOF3Udf1RwMbJ+EHa6Teu3pFmSYrRYdxUhEPXTg+uyohQcm4 W+WeNi7tDVUwWK+kyDsqz4OXi1v22Y4Cq2Tn8= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=yA9ed2MEHEB0CkU+djnITR7Z6MsUaeSwoLJgW+nEQB9JrXXaZF2bS7R5FeHkO8ZWwP oGZ/wfLCnYwEtdYJgUxlcF+9K4GOBTlpcyaMTkQWQjPFrMvK3rgLMkRSFf9WO2TELAnC VXzRcOht/aGVOUb/iNduY3DGeTD1UjK5eFfr8= Received: by 10.142.142.4 with SMTP id p4mr3549770wfd.43.1304372386943; Mon, 02 May 2011 14:39:46 -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 k7sm7545552wfa.14.2011.05.02.14.39.44 (version=SSLv3 cipher=OTHER); Mon, 02 May 2011 14:39:46 -0700 (PDT) Message-ID: <4DBF249E.4020200@gmail.com> Date: Tue, 03 May 2011 09:39:42 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: [Fwd: I-D Action:draft-ietf-6man-flow-ecmp-01.txt] References: <4D52FC43.90203@gmail.com> <201104051745.p35Hjacn018215@cichlid.raleigh.ibm.com> In-Reply-To: <201104051745.p35Hjacn018215@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Mon, 02 May 2011 21:39:48 -0000 On 2011-04-06 05:45, Thomas Narten wrote: > Looking at the revised document, here are some additional comments. > > One lightweight approach to ECMP or LAG is this: if there are N > equally good paths to choose from, then form a modulo(N) hash > [RFC2991] from a consistent set of fields in each packet header > that are certain to have the same values throughout the duration of > a flow, and use the resulting output hash value to select a > particular > > would be nice to have a term better than "consistent". The point is, > you want to use fields that stay constant for a given flow. s/consistent/defined/ > > distribution, due to the pseudo-random nature of ephemeral ports. > Ephemeral port numbers are quite well distributed [Lee10] and will > > is "pseudo-random" right here? IN fact, do we even need that last part > of the sentence? s/pseudo-random/variable/ > > o The flow label in the outer packet SHOULD be set by the sending > TEP to a pseudo-random 20-bit value in accordance with [RFC3697] > or its replacement. The same flow label value MUST be used for > > Don't like this psuedo-random requirement here. And, the TEP should be > setting the Flow Label in *exactly* the same way as 3697bis > recommends. Tunnels are no different... That's true in respect of 3697bis; 3697 was non-specific on this. Fixed by updating the reference; now that the three drafts are bunched together, this makes sense anyway. > > * Note that this rule is a recommendation, to permit individual > implementers to take an alternative approach if they wish to > do so. For example, a simpler solution than a pseudo-random > value might be adopted if it was known that the load balancer > would > > Carpenter & Amante Expires August 14, 2011 [Page 6] > > Internet-Draft Flow Label for tunnel ECMP/LAG February 2011 > > > continue to provide uniform distribution of flows with it. > Such an alternative MUST conform to [RFC3697] or its > replacement. > > > This is too wishy washy. It also suggests that the TEP setting the > Flow Label knows about the algorithm used by the load balancer. That > will rarely (never?) be the case and this document shouldn't suggest > this. Agree, the "For example..." sentence doesn't really add any value. > > the relevant flow label into the outer IPv6 header. A user flow > could be identified by the ingress TEP most simply by its > {destination, source} address 2-tuple (coarse) or by its 5-tuple > {dest addr, source addr, protocol, dest port, source port} (fine). > At present, ironically, there would be little advantage for IPv6 > packets in using the {dest addr, source addr, flow label} 3-tuple. > > Ambiguous. Advantages compared to what? s/advantage for IPv6 packets/point/ > > Also, the Flow classification should simply follow the recommendation > in 3697bis, which says use the 5 tuple, or, at a minimum, the 3 > tuple. The > > The choice of n-tuple is an implementation detail in the sending > TEP. > > No it's not. What may be a detail is the actual algorithm used. But > which fields to use should be a clear recommendation (e.g., taken from > 3697bis). We maintain that whether it uses just the addresses (2-tuple) or up to the whole 5-tuple is not something we can recommend. There could be a major efficiency impact, depending on the design of the router acting as TEP (and we might well be talking about 10 Gbit lines speeds or more). s/detail/choice/ However, re-reading the text made us realise that it doesn't flow quite logically and that now we have clarified 3697bis somewhat, you are correct that we can depend on it more. So the text has been shortened and reorganised, as well as making the above changes. > > * This stateless method creates a small probability of two > different user flows hashing to the same flow label. Since RFC > 3697 allows a source (the TEP in this case) to define any set > of packets that it wishes as a single flow, occasionally > labeling two user flows as a single flow through the tunnel is > acceptable. > > This should be fine. There is no problem with treating packets from 2 > different flows the same way. The problem occurs if packets from > within one flow are treated differently. We agree. > > o At intermediate router(s) that perform load distribution, the hash > algorithm used to determine the outgoing component-link in an ECMP > and/or LAG toward the next-hop MUST minimally include the 3-tuple > {dest addr, source addr, flow label}. This applies whether the > traffic is tunneled traffic only, or a mixture of normal traffic > and tunneled traffic. > > Be more clear: should be 5 tuple, next best is 3. Defer to 3697bis. No, this is a different hash from the one in 3697bis - this is the actual load balancing hash, which is not mentioned there. And again: it's an implementation choice. Some vendors may actively prefer to limit it to the 3-tuple and forget all about transport headers. Added a MAY for components of the 5-tuple (which is slightly redundant with the following sub-bullet). Brian + Shane From rja.lists@gmail.com Tue May 3 02:47:28 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 CB4BFE07B1 for ; Tue, 3 May 2011 02:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Znw+o3YcSVMh for ; Tue, 3 May 2011 02:47:27 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9189DE079D for ; Tue, 3 May 2011 02:47:27 -0700 (PDT) Received: by wwa36 with SMTP id 36so4864673wwa.13 for ; Tue, 03 May 2011 02:47:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=ePYUFtJdpGnrGx4Q5XWVETvyBtfg9mq4nc5Fc76IHss=; b=pIx8+P/RLsE9aBLu5J9cfEmJSyBKIqw6XxbvBwyIGw4cn5VjsW2kAmMDyuMGfLD09w +787ZjNMp9x65Kwfghp94ERe+bD/eUQaUo+8j6Yi/AzauC3BOeMkFeV4+ocmBw3CUiht aYPhZDs2Ad5btbgA2MNIQpoE8EUpW5Yjj0JiE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=fdz21/VWznYsB4pgree1+7MBilyoR4k6sUen3MrJUWKndGwIc08rxPVZ6urtSerDoz pBNIbZ1tu+8NuBMmbPjcUcv2BOrVS3j7qYWs8WOu6fnfXfCJj6gYtoICyG34LfoLauDl R9SIr844wohpHvVtr0bRV4LS1VL2Wk2+Cl/cM= Received: by 10.227.197.201 with SMTP id el9mr4958725wbb.22.1304416045738; Tue, 03 May 2011 02:47:25 -0700 (PDT) Received: from dragonfly.cs.ucl.ac.uk (dragonfly.cs.ucl.ac.uk [128.16.64.246]) by mx.google.com with ESMTPS id ca12sm111779wbb.2.2011.05.03.02.47.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 May 2011 02:47:25 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Flow label drafts updated Date: Tue, 3 May 2011 05:47:23 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 03 May 2011 09:47:28 -0000 Hi, My thanks to all of the editors for their joint work to sort out these drafts and to progress them together. It is substantial work to undertake. The drafts generally seem fine and are eminently readable. However, the "Security Considerations" for both draft-ietf-6man-flow-ecmp-02 and draft-ietf-6man-flow-3697bis seem not to mention the issue where the IPv6 Flow Label field is a relatively high-bandwidth covert channel. This means the Security Considerations for those 2 I-Ds are incomplete. I'm pleased that the covert channel issue is discussed on page 4 of draft-ietf-6man-flow-update-05. This covert channel issue is one reason why a number of deployed IPv6-capable firewalls (and other similar security appliances) clear the IPv6 Flow Label (e.g. in financial/trading environments where M&A information has very high monetary value). I request that this operational security concern, which is entirely legitimate albeit not applicable to all operational environments, at least be mentioned at the top of page 11 of draft-ietf-6man-flow-3697bis (i.e. where the fact that Flow Labels will continue to be zeroed in some deployments is noted). At present, the words there seem to imply that the zeroing behaviour is illogical, silly, and/or wrong -- when in fact it is logical, sensible, and quite correct in certain deployments. I would be MUCH happier if the wording were changed to allow an "operational security" exception to the general principle of not modifying non-zero IPv6 Flow Labels during transit. For example, the wording could say that network devices ought not modify non-zero IPv6 Flow Labels *by default*, leaving it open for users with particular security concerns to configure a non-default configuration (i.e. zeroing the Flow Label). I request that at least a brief mention of the covert channel issue be made in the Security Considerations sections of both draft-ietf-6man-flow-ecmp and draft-ietf-6man-flow-3697bis. If desired, such mentions could refer to the Gont draft or to the -3697bis draft for more detailed discussion of that issue. I am troubled by the apparent decision to ignore legitimate operational security considerations (e.g. about covert channels) and also the apparent decision to write these documents in a manner intended to legislate reasonable security measures (if applicable only in selected deployments) out of existence. This seems to be a case of the IETF levying deployment constraints upon users/operators, which is something that the IETF generally tries to avoid. Yours, Ran Atkinson From narten@us.ibm.com Tue May 3 07:02: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 48EDEE0820 for ; Tue, 3 May 2011 07:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.071 X-Spam-Level: X-Spam-Status: No, score=-104.071 tagged_above=-999 required=5 tests=[AWL=2.528, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 riHKJ5hAuJyM for ; Tue, 3 May 2011 07:02:33 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id 68EB1E0680 for ; Tue, 3 May 2011 07:02:33 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p43DjnBH031639 for ; Tue, 3 May 2011 07:45:49 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p43E2EEH055710 for ; Tue, 3 May 2011 08:02:15 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p43E2Ben013057 for ; Tue, 3 May 2011 08:02:12 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-76-130-219.mts.ibm.com [9.76.130.219]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p43E1lJI011519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 May 2011 08:01:48 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p43E1JLG000418; Tue, 3 May 2011 10:01:20 -0400 Message-Id: <201105031401.p43E1JLG000418@cichlid.raleigh.ibm.com> To: Brian E Carpenter Subject: Re: 6MAN WG Last Call: In-reply-to: <4DBF2362.8040600@gmail.com> References: <201104051740.p35HeoU9018197@cichlid.raleigh.ibm.com> <4DBF2362.8040600@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Tue, 03 May 2011 09:34:26 +1200." Date: Tue, 03 May 2011 10:01:19 -0400 From: Thomas Narten 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: Tue, 03 May 2011 14:02:34 -0000 Hi Brian. Changes look mostly good. Some specific comments. Brian E Carpenter writes: > > Traditionally, flow classifiers have been based on the 5-tuple of the > > source and destination addresses, ports, and the transport > > protocol > > > > add "flow classifiers at the network layer" > Well, using the transport information makes it a layer violation. Do > we really want to open that discussion? What, we can't be honest about what people really are doing and have been doing forever? I don't see why this has to result in some big philosophical discussion... > > > > specification. However, any node that sets flow label values > > according to a stateful scheme MUST ensure that packets conform to > > Section 3 of the present specification if they are sent outside the > > network domain using the stateful scheme. > > > > The above wording regarding "sent outside the network domain" is > > problematic. It hints that maybe you can do things with the Flow Label > > within a domain so long as you don't send such packets outside the > > domain. We shouldn't even hint that that is acceptable. I'd suggest > > removing all references to the "stateful" flow label scheme to one > > section. And that section could be very short. > We agree that this all belongs together in one short paragraph (see > below). But we don't agree to remove the "MUST ensure...". We believe > this is a mandatory constraint on all hypothetical stateful schemes. A requirement saying you cannot modify the Flow Label (unless it is zero) seems awfully clear to me. Why we then also have to say the above is what I don't understand. State the requirement clearly, unambiguously, and once. That should be sufficient. The part that I object to "if they are sent outside the network domain", as it implies that it must be OK to change it within a network domain. If this spec is trying to say that, I object and would like to know why. > > It is desirable that flow label values should be uniformly > > distributed to assist load distribution. It is therefore RECOMMENDED > > that source hosts support the flow label by setting the flow label > > field for all packets of a given flow to the same uniformly > > distributed pseudo-random value. Both stateful and stateless methods > > of assigning a pseudo-random value could be used, but it is outside > > the scope of this specification to mandate an algorithm. In a > > stateless mechanism, the algorithm SHOULD ensure that the resulting > > flow label values are unique with high probability. > > > > I think we need to specify some recommended algorithms. They can be > > SHOULDs (rather than MUST), but saying nothing leaves things too > > unclear. In particular, if we think just doing a simple hash based on > > the port numbers (or something) is good enough, we should recommend > > that. > We're reluctant to use a normative SHOULD in fact - in the end it's an > implementation choice - but yes, we should give clear suggestions - > see new text. I'm not calling for a SHOULD. But I do think it would be helpful to give one or more example algorithms that could be used. The revised version of the document still doesn't give one. > > A source node which does not otherwise set the flow label MUST set > > its value to zero. > > > > Better: just say that the default value should be zero, unless set > > explicitely. > Er, isn't that exactly what the sentence says? Not to me... How can a sender "not otherwise set" a value? It has to set it to something, even if it is just a random value because it doesn't conciously set it... But may that's just me. Below are some additional comments on the revised document itself. Thomas 2011-05-03 Review of -03 Flow label values should be chosen such that their bits exhibit a high degree of variability, making them suitable for use as part of the input to a hash function used in a load distribution scheme. At the same time, third parties should be unlikely to be able to guess the next value that a source of flow labels will choose. s/guess the next value/guess values/ An implementation in which flow labels are assigned sequentially is NOT RECOMMENDED, as it would then be simple for third parties to guess the next value. This then means the examples in gont-security cannot be used? (They generate sequential values....). I think the above is not right, and needs to be more nuanced. I think it would be useful to change "third parties" to "off-path attackers". Those on path will be able to see the values in use, so you are stuck with that. And the algorithm in gont-security presumably are fine to protect against off path attackers. Right? (Thus, I think the above needs tweaking). A node that forwards a flow whose flow label value in arriving packets is zero MAY change the flow label value. reword: A node that forwards a packet whose received flow label value is zero MAY change the flow label value. > 4. Flow State Establishment Requirements > > A node that sets the flow label MAY also take part in a flow state > establishment method that results in assigning specific treatments to > specific flows, possibly including signaling. Any such method MUST > NOT disturb nodes taking part in the stateless model just described. > Thus, any node that sets flow label values according to a stateful > scheme MUST ensure that packets conform to Section 3 of the present > specification if they are sent outside the network domain using the > stateful scheme. Further details are not discussed in this document. The above is a little awkward in places. Suggest the following: A node that sets the flow label MAY also take part in a flow state establishment method that results in assigning specific treatments to specific flows. Such state establishment approaches may include signaling to establish state in routers along the path to the destination. In order to avoid interference with nodes implementing the stateless model described in this document, the assignment of label values MUST satisfy the properties described in Section 3. Further details of stateful Flow State establishment are outside the scope of this document. > This specification defines the flow label as immutable once it has > been set to a non-zero value. However, implementers are advised that > forwarding nodes, especially those acting as domain border devices, > might nevertheless be configured to change the flow label value in > packets. This is undetectable. Again, I object to the above as stated. Getting to Ran's point, if we think that border routers will zero out the Flow Label, let's be honest and state that directly and also *why* (and maybe provide some context about whether that is good/bad/etc.). The above IMO is trying to have it both ways, in a way that no one will understand and will easily be misinterpreted. > 9. Acknowledgements Would be good to more clearly identify the text that applies to this version of the document vs. previous versions. From Internet-Drafts@ietf.org Tue May 3 09:30:07 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 8DDF6E062A; Tue, 3 May 2011 09:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 DzQZkR6PaCGB; Tue, 3 May 2011 09:30:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86ACE0651; Tue, 3 May 2011 09:30:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-6man-node-req-bis-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110503163006.1084.71699.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2011 09:30:06 -0700 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: Tue, 03 May 2011 16:30:07 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : IPv6 Node Requirements RFC 4294-bis Author(s) : E. Jankiewicz, et al Filename : draft-ietf-6man-node-req-bis-09.txt Pages : 30 Date : 2011-04-26 This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC4294. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-6man-node-req-bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-03091912.I-D@ietf.org> --NextPart-- From brian.e.carpenter@gmail.com Wed May 4 23:03:12 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 7A80DE0693 for ; Wed, 4 May 2011 23:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.753 X-Spam-Level: X-Spam-Status: No, score=-102.753 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 xMk2+GncfG4z for ; Wed, 4 May 2011 23:03:12 -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 A7B6EE0692 for ; Wed, 4 May 2011 23:03:11 -0700 (PDT) Received: by bwz13 with SMTP id 13so1788918bwz.31 for ; Wed, 04 May 2011 23:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mmHS9tiUcjfV/DVr4BhtKh2IrxIqCZnC9C/k0cdl164=; b=dXaAuj3LYaxGevmf2u+aT3cGS49K5z8i5MD+wIH9pm9TsGJCIluselYeuP+CpNZS0k eBn4Sdu6+a//UAitX+kKq2VjboUHp0aPrsHdAeKw9OtDEaVKouW4byrd8jiY7xOlfNEm HjHtsuOLutLFQmPZoIgz2okV0kAhheN5Zhxgw= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=JVrXRay6sySbfzCe4/g2d5cNBkbu2woszCAMd16oLJFxH7BHWgj++t3SYKiNDITFJF GgaxA8VjRSNZly/go93JCTYt85Q72lqra45c67CliKsU4OkxUrkL9vmzMbb0sDqk2tP6 bSmsezXKPAEuaL5UFN0rmCEiGQTrVZL6JdjeE= Received: by 10.204.230.194 with SMTP id jn2mr1845504bkb.133.1304574965651; Wed, 04 May 2011 22:56:05 -0700 (PDT) Received: from [10.1.1.5] ([121.98.251.219]) by mx.google.com with ESMTPS id c11sm1150375bkc.2.2011.05.04.22.56.02 (version=SSLv3 cipher=OTHER); Wed, 04 May 2011 22:56:04 -0700 (PDT) Message-ID: <4DC07A80.2030200@gmail.com> Date: Wed, 04 May 2011 09:58:24 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: Flow label drafts updated References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 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, 05 May 2011 06:03:12 -0000 Ran, > I am troubled by the apparent decision to ignore legitimate > operational security considerations (e.g. about covert channels) We should certainly mention the covert channels issue in the security considerations of 3697bis. > and also the apparent decision to write these documents > in a manner intended to legislate reasonable security measures > (if applicable only in selected deployments) out of existence. I don't understand this comment. The flow label has always been defined as immutable; the consensus in the WG is to keep that property. So a firewall that overwrites it is unambiguously breaking the standard. Regards Brian On 2011-05-03 21:47, RJ Atkinson wrote: > Hi, > > My thanks to all of the editors for their joint work to sort out > these drafts and to progress them together. It is substantial > work to undertake. The drafts generally seem fine and are > eminently readable. > > However, the "Security Considerations" for both > draft-ietf-6man-flow-ecmp-02 and draft-ietf-6man-flow-3697bis > seem not to mention the issue where the IPv6 Flow Label field > is a relatively high-bandwidth covert channel. This means the > Security Considerations for those 2 I-Ds are incomplete. > > I'm pleased that the covert channel issue is discussed on page 4 > of draft-ietf-6man-flow-update-05. This covert channel issue is > one reason why a number of deployed IPv6-capable firewalls (and > other similar security appliances) clear the IPv6 Flow Label > (e.g. in financial/trading environments where M&A information > has very high monetary value). > > I request that this operational security concern, which is entirely > legitimate albeit not applicable to all operational environments, > at least be mentioned at the top of page 11 of draft-ietf-6man-flow-3697bis > (i.e. where the fact that Flow Labels will continue to be zeroed > in some deployments is noted). At present, the words there seem > to imply that the zeroing behaviour is illogical, silly, and/or wrong > -- when in fact it is logical, sensible, and quite correct in certain > deployments. I would be MUCH happier if the wording were changed > to allow an "operational security" exception to the general > principle of not modifying non-zero IPv6 Flow Labels during transit. > For example, the wording could say that network devices ought > not modify non-zero IPv6 Flow Labels *by default*, leaving it > open for users with particular security concerns to configure > a non-default configuration (i.e. zeroing the Flow Label). > > I request that at least a brief mention of the covert channel > issue be made in the Security Considerations sections of both > draft-ietf-6man-flow-ecmp and draft-ietf-6man-flow-3697bis. > If desired, such mentions could refer to the Gont draft or > to the -3697bis draft for more detailed discussion of that > issue. > > I am troubled by the apparent decision to ignore legitimate > operational security considerations (e.g. about covert channels) > and also the apparent decision to write these documents > in a manner intended to legislate reasonable security measures > (if applicable only in selected deployments) out of existence. > This seems to be a case of the IETF levying deployment > constraints upon users/operators, which is something that the > IETF generally tries to avoid. > > Yours, > > Ran Atkinson > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From rja.lists@gmail.com Thu May 5 05:56:01 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 B44ECE076D for ; Thu, 5 May 2011 05:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 r42af2B3zogL for ; Thu, 5 May 2011 05:56:01 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F19EDE0756 for ; Thu, 5 May 2011 05:56:00 -0700 (PDT) Received: by wyb29 with SMTP id 29so1823433wyb.31 for ; Thu, 05 May 2011 05:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=ZKYtp8bH/8UPlrCwcmwDxrk5TybgBctBVHVegIGu5RI=; b=lMzXCfvjxxNBBBUU1JEh4jNfDaAbdnxmNO1/c2LUyeKl1icVs8Dt+zihKucd2BZz/5 EEZ6JBCwlxXQzEtbpRzn/3saeEHXmmJ6UwnxTudC4waqRzfF862k0XtQsAJq90hQTNdf KLEM/QFsT1E9w09kjXFbyACcEDFp6zmhkbr28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=qgVbWxmvFxV3d6fLM5Jkr4KLbZ3WkhN23Xh3XcnwnjvKfgHgT0L7nGC7iMQPaS7Utz eN8d22z7pVygWkF4yaa/tNpdL24OW8Fi7srtJtK/VP6yhgoZWaNsGh+I8MStvZ0EHBue lv3T9THE7oCZh4gp785AgS8LsjX2gox4cTZzM= Received: by 10.227.178.202 with SMTP id bn10mr2580161wbb.16.1304600159825; Thu, 05 May 2011 05:55:59 -0700 (PDT) Received: from dragonfly.cs.ucl.ac.uk (dragonfly.cs.ucl.ac.uk [128.16.64.246]) by mx.google.com with ESMTPS id ca12sm1337268wbb.53.2011.05.05.05.55.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2011 05:55:59 -0700 (PDT) Subject: Re: Flow label drafts updated Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: RJ Atkinson In-Reply-To: <4DC07A80.2030200@gmail.com> Date: Thu, 5 May 2011 08:55:57 -0400 Content-Transfer-Encoding: 7bit Message-Id: <09C574A2-37D4-4507-A3F8-9B68F95FAE16@gmail.com> References: <4DC07A80.2030200@gmail.com> To: Brian E Carpenter 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: Thu, 05 May 2011 12:56:01 -0000 On 03 May 2011, at 17:58 , Brian E Carpenter wrote: >> and also the apparent decision to write these documents >> in a manner intended to legislate reasonable security measures >> (if applicable only in selected deployments) out of existence. > > I don't understand this comment. The flow label has always been > defined as immutable; the consensus in the WG is to keep that > property. So a firewall that overwrites it is unambiguously > breaking the standard. Brian, The flow label has been modified by routers/security gateways for many years now. It is not a new event. I was first aware of it circa 1997. As near as I can tell, this has been done for security reasons the whole time. Those security reasons are in fact reasonable, albeit not applicable to all environments. Pretending those legitimate security considerations don't exist is actively harmful, which is why the operational practice is not new. IPv6 specifications should reflect reality, not a theoretical world that we know does not exist (and never has, or at least hasn't existed for ~15 years now). I proposed edits that are reasonable. This WG has not considered those edits. It is not obvious to me that there is any consensus, either way, on the current wording or on the proposed wording. There should be further WG discussion if you really believe the proposed edit is technically unsoundl, otherwise the edit ought to be made (or a wordsmithed version of it). Yours, Ran From Wesley.E.George@sprint.com Thu May 5 06:48:53 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 A4F7BE076E for ; Thu, 5 May 2011 06:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.954 X-Spam-Level: X-Spam-Status: No, score=-3.954 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 R5WOBZGRo2Pc for ; Thu, 5 May 2011 06:48:52 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 8186BE0593 for ; Thu, 5 May 2011 06:48:52 -0700 (PDT) Received: from mail45-ch1-R.bigfish.com (216.32.181.172) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.8; Thu, 5 May 2011 13:48:51 +0000 Received: from mail45-ch1 (localhost.localdomain [127.0.0.1]) by mail45-ch1-R.bigfish.com (Postfix) with ESMTP id 99966197876D; Thu, 5 May 2011 13:48:51 +0000 (UTC) X-SpamScore: -27 X-BigFish: VS-27(zz9371Ozz1202hzz1033IL8275dhz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm1.corp.sprint.com; RD:smtpda1.sprint.com; EFVD:NLI Received: from mail45-ch1 (localhost.localdomain [127.0.0.1]) by mail45-ch1 (MessageSwitch) id 1304603331376424_379; Thu, 5 May 2011 13:48:51 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail45-ch1.bigfish.com (Postfix) with ESMTP id 5550266004D; Thu, 5 May 2011 13:48:51 +0000 (UTC) Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.8; Thu, 5 May 2011 13:48:47 +0000 Received: from PLSWEH03.ad.sprint.com (PLSWEH03.corp.sprint.com [144.226.242.132]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p45Dmhh7003544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 May 2011 08:48:44 -0500 Received: from PDAWM12B.ad.sprint.com ([fe80::64c8:fd69:1029:79b0]) by PLSWEH03.ad.sprint.com ([fe80::a470:17cb:6a7f:3a52%15]) with mapi id 14.01.0270.001; Thu, 5 May 2011 08:48:44 -0500 From: "George, Wes E [NTK]" To: Brian E Carpenter , RJ Atkinson Subject: RE: Flow label drafts updated Thread-Topic: Flow label drafts updated Thread-Index: AQHMCupC+LzQmP1oP067WfuFzharr5R+NFJg Date: Thu, 5 May 2011 13:48:42 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> References: <4DC07A80.2030200@gmail.com> In-Reply-To: <4DC07A80.2030200@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.26] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0018_01CC0B09.9E0969D0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com 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, 05 May 2011 13:48:53 -0000 ------=_NextPart_000_0018_01CC0B09.9E0969D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Tuesday, May 03, 2011 5:58 PM Subject: Re: Flow label drafts updated > and also the apparent decision to write these documents in a manner > intended to legislate reasonable security measures (if applicable only > in selected deployments) out of existence. I don't understand this comment. The flow label has always been defined as immutable; the consensus in the WG is to keep that property. So a firewall that overwrites it is unambiguously breaking the standard. [WEG] now it's my turn to be confused by your comment, Brian. I missed this detail of interpretation when reviewing the draft for LC, and I apologize, but I think it's pretty important... >From the 3697bis draft: "There is no way to verify whether a flow label has been modified en route or whether it belongs to a uniform distribution. Therefore, no Internet-wide mechanism can depend mathematically on immutable and uniformly distributed flow labels; they have a "best effort" quality." But it goes on to say: " This specification defines the flow label as immutable once it has been set to a non-zero value. However, implementers are advised that forwarding nodes, especially those acting as domain border devices, might nevertheless be configured to change the flow label value in packets. This is undetectable." My interpretation of the above is that it functionally renders the flow label mutable. If one cannot assume that the flow label will arrive at its destination with the original value intact, nor detect when it has been changed, it is by definition mutable and it's nonsensical to have this discussed in such an ambiguous way in the draft, because no implementer in their right mind is going to try to use this for an application that needs the label to be immutable in all cases. This draft should be correcting the fundamentally flawed assumption that an unprotected field can be immutable. I don't see how Ran's comments would be a different case and (apparently) a different interpretation of the above. I don't recall consensus forming around this idea of immutable, but with asterisks instead of simply acknowledging that regardless of what the standard said before, the label has always been mutable since it's unprotected. However, I've had a couple of gaps where $day_job has taken precedence over IETF lists, so I might have missed a part of that discussion. Apologies if I'm rehashing. Perhaps the chairs would like to offer an interpretation? Wes George ------=_NextPart_000_0018_01CC0B09.9E0969D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwNTEz NDg0MlowIwYJKoZIhvcNAQkEMRYEFEjxcXHIv+s0UrfItoxRSbtlrRbHMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgLGFoHCiswDDRrK17/i4N5XuTsemqnQv3xwYImdJyJWOP7C0Jnnr9N3zn9IYGZTwHsxW aEnEFQLk70AG+v1ASyP7nb3gHLgLsSiExI9G9Y5ZBbswf/NxA5zvmBMOGSmDmNFkauQCuDtl0cuV NNmnj4ShlnveBaaDBcVtvoPMopWzAAAAAAAA ------=_NextPart_000_0018_01CC0B09.9E0969D0-- From ichiroumakino@gmail.com Thu May 5 06:49:12 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 1205EE0593 for ; Thu, 5 May 2011 06:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.291 X-Spam-Level: X-Spam-Status: No, score=-3.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 iNR9+Rc0Xaqt for ; Thu, 5 May 2011 06:49:11 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9D8E0779 for ; Thu, 5 May 2011 06:49:11 -0700 (PDT) Received: by wwa36 with SMTP id 36so1643373wwa.13 for ; Thu, 05 May 2011 06:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=aqzNVfbtZvasZce35ImyJfdtk6r5UvGAM+NTLmnowYQ=; b=dnThHfHG3R1cVbOico+Lgpj9WsR0eyZSJTliKttCZkVDf/aZJ3tNJWGjXgAbfKBh7/ mv+qeO4PhyyGdk1Yth+C3lQauhu5HxnZU/7/bYDWlYXmSDy5h6mviIK3rzqPrzyBIMHT 27Xhe4e23DY8Eo4YFlLznoOk2vK8lArbu73Ew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=uo+SNXo/vbqVhyrxZ7/O5gx50Qs/Mwm5ZmZmCFnu3VnyiVPbsp1ZzezpoYTmIT8aEu hfaAdAyKxAr5V0ItdtNZsmqxdOhu2WEOPAkRNMefIztvCH3RGZdHVrAFINZ95/kVl06X 0pVlSR4NjBVJwoR4k+c0ld9Z9FkGBYVshGbAM= Received: by 10.227.176.135 with SMTP id be7mr2589176wbb.0.1304603349859; Thu, 05 May 2011 06:49:09 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-245.cisco.com (dhcp-osl-vl300-64-103-53-245.cisco.com [64.103.53.245]) by mx.google.com with ESMTPS id t16sm363057wbg.6.2011.05.05.06.49.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2011 06:49:08 -0700 (PDT) Sender: Ole Troan Subject: Re: Short 6MAN WG Last Call: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Thu, 5 May 2011 15:49:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> References: To: Bob Hinden X-Mailer: Apple Mail (2.1084) 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: Thu, 05 May 2011 13:49:12 -0000 I'm on the fence with regards to this document. if this document is = meant to be the RFC1122/1812 document for IPv6, I think we are too early in the deployment of IPv6 to have gathered = enough experience with what works and what doesn't. as a profile of an IPv6 node though, it isn't too far off. a couple of comments: * section 5.3. Default Router Preferences and More-Specific Routes - = RFC 4191 this is a "MAY wish" and in conflict with RFC6204, L-3. please make this a SHOULD or even a MUST (as hosts not supporting it = will not be able to interoperate on networks behind RFC6204 routers. * RFC2675: I would just remove that. * 5.9.4 Default Address Selection As RFC3484 generates IPv6 brokenness. I think we should change this = reference to RFC3484bis. * 5.9.5. Stateful Address Autoconfiguration I still disagree with the MAY for DHCP. I don't think we should state = the 'at the present time SLAAC'. hosts that cannot do DHCP for address assignment may not be able to = connect to many cable networks (see DOCSIS 3) and access networks specified by the BBF. * 6 DHCP vs. Router Advertisement Options for Host Configuration I don't understand the purpose of this section. it should include text explaining how to handle conflicts between = multiple mechanisms if anything. and make it clear that every node has to implement all mechanisms. = that's the natural consequence of designing multiple ways of doing the same thing. * 8.1. Transition Mechanisms Just remove the section. it doesn't add value. * 12.1.1 Router Alert not just acknowledge that the HBH option was a bad idea and nuke it? cheers, Ole= From bob.hinden@gmail.com Thu May 5 10:31: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 316A0E08EE for ; Thu, 5 May 2011 10:31:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtnDHROlQyIz for ; Thu, 5 May 2011 10:31:01 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 79791E08ED for ; Thu, 5 May 2011 10:31:01 -0700 (PDT) Received: by pzk5 with SMTP id 5so1382901pzk.31 for ; Thu, 05 May 2011 10:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=LY+22oTh2yS7HH0cHILCD8gR1zit54lgTsRPDkXsx1s=; b=oOMgADeG8jnreQLzmcwzVUnV+Lslr4QEFceSvsrQ6b8M74jVGAJ7vASg2yVY7gAZ9T mN+I37ZVApWTgYQqJ4DyFIPPNutFOd6u/LxWlywrALzAZFY66oUAr2H6qVYy29M6fynm jCPwtfn4rT530KOhTVZAmn9dK3WcsPwJ0GWco= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=vqgzcJQqsnPGWk6W7U2xMNhd08yLrGmz047lQrOajewQWTxjHmji8MqxZCZtAv3Rt7 hQ1Xg/MZ5WAn7osNKo0GFNno2L1hxGHjHxOOnU4V34Eu1DJg4Udr+A7bFgOhQ8XpGLGY VOvKe4yq0jqJTe8P1GbYNQi4N6BVh/c702T+w= Received: by 10.68.6.99 with SMTP id z3mr3446482pbz.331.1304616661246; Thu, 05 May 2011 10:31:01 -0700 (PDT) Received: from [10.0.0.37] (c-24-130-225-13.hsd1.ca.comcast.net [24.130.225.13]) by mx.google.com with ESMTPS id y8sm1557005pba.51.2011.05.05.10.30.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2011 10:30:59 -0700 (PDT) Subject: Re: Short 6MAN WG Last Call: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> Date: Thu, 5 May 2011 10:30:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1084) Cc: 6man Mailing List , Brian Haberman , Bob Hinden 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, 05 May 2011 17:31:02 -0000 Ole, On May 5, 2011, at 6:49 AM, Ole Troan wrote: > I'm on the fence with regards to this document. if this document is = meant to be the RFC1122/1812 document for IPv6, > I think we are too early in the deployment of IPv6 to have gathered = enough experience with what works and what doesn't. > as a profile of an IPv6 node though, it isn't too far off. This is, of course, and update the the current Node Requirements as = define in RFC4294. Weither it is the last update, is anyones guess, but = I think it clearly better to update it now as we know there are many = things that are wrong with RFC4294. I would also note that RFC1122 was written in 1989 and RFC1812 in 1995. = Neither of those reflect current practice with IPv4. We might be at the = same point of deployment with IPv6 as IPv4 was in 1989 :-) Bob >=20 > a couple of comments: >=20 > * section 5.3. Default Router Preferences and More-Specific Routes - = RFC 4191 > this is a "MAY wish" and in conflict with RFC6204, L-3. > please make this a SHOULD or even a MUST (as hosts not supporting it = will not be able to interoperate on networks behind > RFC6204 routers. >=20 > * RFC2675: I would just remove that. >=20 > * 5.9.4 Default Address Selection > As RFC3484 generates IPv6 brokenness. I think we should change this = reference to RFC3484bis. >=20 > * 5.9.5. Stateful Address Autoconfiguration > I still disagree with the MAY for DHCP. I don't think we should state = the 'at the present time SLAAC'. > hosts that cannot do DHCP for address assignment may not be able to = connect to many cable networks (see DOCSIS 3) > and access networks specified by the BBF. >=20 > * 6 DHCP vs. Router Advertisement Options for Host Configuration > I don't understand the purpose of this section. > it should include text explaining how to handle conflicts between = multiple mechanisms if anything. > and make it clear that every node has to implement all mechanisms. = that's the natural consequence > of designing multiple ways of doing the same thing. >=20 > * 8.1. Transition Mechanisms > Just remove the section. it doesn't add value. >=20 > * 12.1.1 Router Alert > not just acknowledge that the HBH option was a bad idea and nuke it? >=20 > cheers, > Ole From john.loughney@nokia.com Thu May 5 10:35: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 C4C53E067F for ; Thu, 5 May 2011 10:35:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CltOURKUpzJ for ; Thu, 5 May 2011 10:35:22 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id B7DA3E0753 for ; Thu, 5 May 2011 10:35:22 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p45HZ1B6002421; Thu, 5 May 2011 20:35:17 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 May 2011 20:35:05 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 5 May 2011 19:35:04 +0200 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.183]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0289.008; Thu, 5 May 2011 19:35:04 +0200 From: To: , Subject: RE: Short 6MAN WG Last Call: Thread-Topic: Short 6MAN WG Last Call: Thread-Index: AQHMBouUVucckJc8M0CGOJDun35LeJR+J8SAgAA9/oCAACHwEA== Date: Thu, 5 May 2011 17:35:04 +0000 Message-ID: <1571128F4B736C42B743F492521F123B1E0BA6@008-AM1MPN1-003.mgdnok.nokia.com> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.243.186.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 May 2011 17:35:05.0400 (UTC) FILETIME=[C5633380:01CC0B4A] X-Nokia-AV: Clean Cc: brian@innovationslab.net, 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, 05 May 2011 17:35:23 -0000 I agree with Bob. Also, the world is a bit different than in 1989 and 1995= . There are a lot of organizations creating different IPv6 'profiles', 'ce= rtifications' and guidelines. I think it has always been our intention to = use the Node Requirements to provide some guidelines from the IETF point of= view. We can review some of your specific comments, though. =20 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of ext= Bob Hinden Sent: Thursday, May 05, 2011 10:31 AM To: Ole Troan Cc: 6man Mailing List; Brian Haberman; Bob Hinden Subject: Re: Short 6MAN WG Last Call: Ole, On May 5, 2011, at 6:49 AM, Ole Troan wrote: > I'm on the fence with regards to this document. if this document is=20 > meant to be the RFC1122/1812 document for IPv6, I think we are too early = in the deployment of IPv6 to have gathered enough experience with what work= s and what doesn't. > as a profile of an IPv6 node though, it isn't too far off. This is, of course, and update the the current Node Requirements as define = in RFC4294. Weither it is the last update, is anyones guess, but I think i= t clearly better to update it now as we know there are many things that are= wrong with RFC4294. I would also note that RFC1122 was written in 1989 and RFC1812 in 1995. Ne= ither of those reflect current practice with IPv4. We might be at the same= point of deployment with IPv6 as IPv4 was in 1989 :-) Bob >=20 > a couple of comments: >=20 > * section 5.3. Default Router Preferences and More-Specific Routes -=20 > RFC 4191 this is a "MAY wish" and in conflict with RFC6204, L-3. > please make this a SHOULD or even a MUST (as hosts not supporting it=20 > will not be able to interoperate on networks behind > RFC6204 routers. >=20 > * RFC2675: I would just remove that. >=20 > * 5.9.4 Default Address Selection > As RFC3484 generates IPv6 brokenness. I think we should change this refe= rence to RFC3484bis. >=20 > * 5.9.5. Stateful Address Autoconfiguration I still disagree with=20 > the MAY for DHCP. I don't think we should state the 'at the present time = SLAAC'. > hosts that cannot do DHCP for address assignment may not be able to=20 > connect to many cable networks (see DOCSIS 3) and access networks specif= ied by the BBF. >=20 > * 6 DHCP vs. Router Advertisement Options for Host Configuration I=20 > don't understand the purpose of this section. > it should include text explaining how to handle conflicts between multip= le mechanisms if anything. > and make it clear that every node has to implement all mechanisms.=20 > that's the natural consequence of designing multiple ways of doing the s= ame thing. >=20 > * 8.1. Transition Mechanisms > Just remove the section. it doesn't add value. >=20 > * 12.1.1 Router Alert > not just acknowledge that the HBH option was a bad idea and nuke it? >=20 > cheers, > Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From Internet-Drafts@ietf.org Thu May 5 14:45: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 89A48E07DE; Thu, 5 May 2011 14:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] 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 46z3E4VTrSAD; Thu, 5 May 2011 14:45:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EBEE074D; Thu, 5 May 2011 14:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-ietf-6man-udpzero-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110505214502.1710.74933.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 14:45:02 -0700 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, 05 May 2011 21:45:02 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF. Title : IPv6 UDP Checksum Considerations Author(s) : G. Fairhurst, et al Filename : draft-ietf-6man-udpzero-03.txt Pages : 33 Date : 2011-04-21 This document examines the role of the UDP transport checksum when used with IPv6, as defined in RFC2460. It presents a summary of the trade-offs for evaluating the safety of updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value in the checksum field as an indication that no checksum is present. This method is compared with some other possibilities. The document also describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations. It concludes that UDP with a zero checksum in IPv6 can safely be used for this purpose, provided that this usage is governed by a set of constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-udpzero-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-6man-udpzero-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-05143407.I-D@ietf.org> --NextPart-- From fernando.gont.netbook@gmail.com Thu May 5 16:52: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 252A1E0730 for ; Thu, 5 May 2011 16:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 e9o0C5F6+dJ8 for ; Thu, 5 May 2011 16:52:54 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 87094E0713 for ; Thu, 5 May 2011 16:52:54 -0700 (PDT) Received: by pwi5 with SMTP id 5so1557411pwi.31 for ; Thu, 05 May 2011 16:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CP669XBPCERj95P9E3OIkmlBYazunptesOPR61NerDM=; b=IIJiQQOPD4F7oOE+IMa+8vRZN9SL/QqP5a5a53y/Jh7LBMB9FWajQauVhHTPj72/7n 59BFIQODFhsFEXaMy5xs6izm5yreTtPzgV1GSqYwEbOAvraDivJQ6jkQkaPuUmjsXhGN cUqnKZ23fNjzO2+gN7GF9mPO4/k0j5xWv+0Jg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ot/U/p1kxeq1EZWDa0a+8hg2JwFH3pm8DnfpXX9vea5LNrOpUT8uBWWpI7uVBDqatP pjtejTVfdQ5IC7Y8L70zw4l8eqlIUP7hJyVz8nk7iY+Iwkk5gVpPykNh+UuYDwsJBO58 UMHzaHc2fXEpwKisC9LlDrbXh1nEXAbwznL3M= MIME-Version: 1.0 Received: by 10.68.35.135 with SMTP id h7mr2917110pbj.493.1304639574064; Thu, 05 May 2011 16:52:54 -0700 (PDT) Sender: fernando.gont.netbook@gmail.com Received: by 10.68.58.163 with HTTP; Thu, 5 May 2011 16:52:54 -0700 (PDT) In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> References: <4DC07A80.2030200@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> Date: Thu, 5 May 2011 20:52:54 -0300 X-Google-Sender-Auth: NezfaJUgGgXdwzA9SUMEmQqHcq4 Message-ID: Subject: Re: Flow label drafts updated From: Fernando Gont To: "George, Wes E [NTK]" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" , RJ Atkinson , Brian E Carpenter 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, 05 May 2011 23:52:55 -0000 +1 On Thu, May 5, 2011 at 10:48 AM, George, Wes E [NTK] wrote: > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of B= rian E Carpenter > Sent: Tuesday, May 03, 2011 5:58 PM > Subject: Re: Flow label drafts updated > >> and also the apparent decision to write these documents in a manner >> intended to legislate reasonable security measures (if applicable only >> in selected deployments) out of existence. > > I don't understand this comment. The flow label has always been defined a= s immutable; the consensus in the WG is to keep that > property. So a firewall that overwrites it is unambiguously breaking the = standard. > > [WEG] now it's my turn to be confused by your comment, Brian. I missed th= is detail of interpretation when reviewing the draft for > LC, and I apologize, but I think it's pretty important... > From the 3697bis draft: > "There is no way to verify whether a flow label has been modified en > =A0 route or whether it belongs to a uniform distribution. =A0Therefore, = no > =A0 Internet-wide mechanism can depend mathematically on immutable and > =A0 uniformly distributed flow labels; they have a "best effort" quality.= " > =A0But it goes on to say: > " This specification defines the flow label as immutable once it has > =A0 been set to a non-zero value. =A0However, implementers are advised th= at > =A0 forwarding nodes, especially those acting as domain border devices, > =A0 might nevertheless be configured to change the flow label value in > =A0 packets. =A0This is undetectable." > My interpretation of the above is that it functionally renders the flow l= abel mutable. If one cannot assume that the flow label will > arrive at its destination with the original value intact, nor detect when= it has been changed, it is by definition mutable and it's > nonsensical to have this discussed in such an ambiguous way in the draft,= because no implementer in their right mind is going to try > to use this for an application that needs the label to be immutable in al= l cases. This draft should be correcting the fundamentally > flawed assumption that an unprotected field can be immutable. I don't see= how Ran's comments would be a different case and > (apparently) a different interpretation of the above. > > I don't recall consensus forming around this idea of immutable, but with = asterisks instead of simply acknowledging that regardless > of what the standard said before, the label has always been mutable since= it's unprotected. However, I've had a couple of gaps where > $day_job has taken precedence over IETF lists, so I might have missed a p= art of that discussion. Apologies if I'm rehashing. Perhaps > the chairs would like to offer an interpretation? > > Wes George > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From narten@us.ibm.com Fri May 6 06:27:12 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 41576E0691 for ; Fri, 6 May 2011 06:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.209 X-Spam-Level: X-Spam-Status: No, score=-106.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 j9f5Qwnyke75 for ; Fri, 6 May 2011 06:27:11 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB42E067A for ; Fri, 6 May 2011 06:27:10 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p46DFg7b012008 for ; Fri, 6 May 2011 07:15:42 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p46DQoA3140360 for ; Fri, 6 May 2011 07:26:54 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p467QfBL018832 for ; Fri, 6 May 2011 01:26:42 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-202-160.mts.ibm.com [9.65.202.160]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p467QeaA018784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 May 2011 01:26:41 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p46DQksH014118; Fri, 6 May 2011 09:26:47 -0400 Message-Id: <201105061326.p46DQksH014118@cichlid.raleigh.ibm.com> To: "George, Wes E [NTK]" Subject: Re: Flow label drafts updated In-reply-to: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> References: <4DC07A80.2030200@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> Comments: In-reply-to "George, Wes E [NTK]" message dated "Thu, 05 May 2011 13:48:42 -0000." Date: Fri, 06 May 2011 09:26:46 -0400 From: Thomas Narten Cc: "ipv6@ietf.org" , RJ Atkinson , Brian E Carpenter 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, 06 May 2011 13:27:12 -0000 "George, Wes E [NTK]" writes: > [WEG] now it's my turn to be confused by your comment, Brian. I missed this detail of interpretation when reviewing the draft for > LC, and I apologize, but I think it's pretty important... > >From the 3697bis draft: > "There is no way to verify whether a flow label has been modified en > route or whether it belongs to a uniform distribution. Therefore, no > Internet-wide mechanism can depend mathematically on immutable and > uniformly distributed flow labels; they have a "best effort" quality." > But it goes on to say: > " This specification defines the flow label as immutable once it has > been set to a non-zero value. However, implementers are advised that > forwarding nodes, especially those acting as domain border devices, > might nevertheless be configured to change the flow label value in > packets. This is undetectable." > My interpretation of the above is that it functionally renders the > flow label mutable. I think we are getting too hung up on definitions. Is the UDP port number mutable? Is the TCP sequence number immutable? There are ways of modifying them that are undetecable. Does that make them mutable? The intention is that the Flow Label not get modified. Doing so can impact its usefulness. This is true of most fields in packets. If random actors start tweaking various fields in a packet, that tends to not be helpful (or worse). I do think the document needs to say something about covert channels and border routers zeroing out the field (and not just stick its head in the sand and try to have it both ways, which the wording Wes quoted effectively does). But that doesn't mean we are declaring that the field is "mutable", implying that anyone can start doing with it what they want. Thomas From narten@us.ibm.com Fri May 6 10:48:33 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 6BF1AE07B2 for ; Fri, 6 May 2011 10:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.222 X-Spam-Level: X-Spam-Status: No, score=-106.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 awBCtlYbHFy7 for ; Fri, 6 May 2011 10:48:32 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5CAE078A for ; Fri, 6 May 2011 10:48:32 -0700 (PDT) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e7.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p46HPbaN007219 for ; Fri, 6 May 2011 13:25:37 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p46HmN5h1196072 for ; Fri, 6 May 2011 13:48:23 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p46HmMtH009432 for ; Fri, 6 May 2011 14:48:23 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-202-160.mts.ibm.com [9.65.202.160]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p46HmLn6009412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 May 2011 14:48:21 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p46HmJu8015684; Fri, 6 May 2011 13:48:20 -0400 Message-Id: <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> To: Ole Troan Subject: Re: Short 6MAN WG Last Call: In-reply-to: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> Comments: In-reply-to Ole Troan message dated "Thu, 05 May 2011 15:49:03 +0200." Date: Fri, 06 May 2011 13:48:19 -0400 From: Thomas Narten Cc: 6man Mailing List , Brian Haberman , Bob Hinden 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, 06 May 2011 17:48:33 -0000 Hi Ole. Thanks for the review! > I'm on the fence with regards to this document. if this document is > meant to be the RFC1122/1812 document for IPv6, I think we are too > early in the deployment of IPv6 to have gathered enough experience > with what works and what doesn't. as a profile of an IPv6 node > though, it isn't too far off. As Bob says, this is a revision of an existing document. Its a much more current set of recommendations than RFC 4294. > a couple of comments: > * section 5.3. Default Router Preferences and More-Specific Routes - RFC 4191 > this is a "MAY wish" and in conflict with RFC6204, L-3. > please make this a SHOULD or even a MUST (as hosts not supporting it will not be able to interoperate on networks behind > RFC6204 routers. I'm not entirely sure what to do here. RFC 4191 is not widely implemented, AFAIK. It's in Windows Vista (and onwards) and also Linux. Not sure where else (I'm guessing not on Macs?) So, I'm not at all sure we should recommend it as a SHOULD. IMO, its not a crucial document, and its not widely implemented. Can someone explain to me the rationale for mandating 4191 in 6204? What was the scenario that was envisioned that necessitates 4191? > * RFC2675: I would just remove that. The docuent currently says: IPv6 Jumbograms [RFC2675] MAY be supported. How about I replace that with: IPv6 Jumbograms [RFC2675] are an optional extension that allow the sending of IP datagrams larger than 65.535 bytes. IPv6 Jumbograms make use of IPv6 hop-by-hop options and are only suitable on paths in which every hop and link are capable of supporting Jumbograms (e.g., within a campus or datacenter). To date, few implementations exist and there is essentially no reported experience from usage. Consequently, IPv6 Jumbograms [RFC2675] remain optional at this time. (key change is "MAY" to just lower case "optional"). > * 5.9.4 Default Address Selection > As RFC3484 generates IPv6 brokenness. I think we should change > this reference to RFC3484bis. Can't do that. That would delay publication of the RFC. BTW, you could make the same arguement w.r.t. the Flow Label. And possibly other things that are still in revision... > * 5.9.5. Stateful Address Autoconfiguration > I still disagree with the MAY for DHCP. I don't think we should > state the 'at the present time SLAAC'. Note: full quote is: At the present time, the configuration of stateless address autoconfiguration is more widely implemented in hosts than address configuration through DHCP. This would appear to be statement of fact. (And on rereading it, I would suggestion changing the sentence to: At the present time, the configuration of addresses via stateless autoconfiguration is more widely implemented in hosts than address configuration via DHCP. > hosts that cannot do DHCP for address assignment may not be able > to connect to many cable networks (see DOCSIS 3) Is this true for *end user* hosts at behind a DOCSYS modem? I believe not. > and access networks specified by the BBF. IMO, the day of having CPE devices support bridging are gone. It is perfectly fine to require the use of a router rather than allowing end clients to connect directly. Such routers could be required to implement DHC. But you can't reasonably expect all client end devices to support it. We missed the boat on that years ago. > * 6 DHCP vs. Router Advertisement Options for Host Configuration > I don't understand the purpose of this section. It is a bit of history/background. > it should include text explaining how to handle conflicts between multiple mechanisms if anything. The existing specifications already address this. This document has nothing to add. > and make it clear that every node has to implement all > mechanisms. that's the natural consequence of designing multiple > ways of doing the same thing. The WG has not been willing to do that. Unless something has changed recently, I do not see support for elevating DHC support beyond MAY (for addresses anyway). > * 8.1. Transition Mechanisms > Just remove the section. it doesn't add value. I agree there isn't much there, but for completeness, I think it should stay. > * 12.1.1 Router Alert > not just acknowledge that the HBH option was a bad idea and nuke it? Not sure what your point is here. HBH options are mandatory to implement at this time. Way to late to deprecate them. Neighbor Discovery depends on it (i.e., MLD mandates it, and you need MLD for ND). Thomas From ichiroumakino@gmail.com Fri May 6 11:54: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 E549DE0771 for ; Fri, 6 May 2011 11:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.634 X-Spam-Level: X-Spam-Status: No, score=-3.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 BPlZ8csThdgx for ; Fri, 6 May 2011 11:54:31 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 791C7E0768 for ; Fri, 6 May 2011 11:54:31 -0700 (PDT) Received: by eye13 with SMTP id 13so1249480eye.31 for ; Fri, 06 May 2011 11:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=SWJdOQfMZgr8wGc/epWJ0RewkMsMd+PmLmGB+2rfsuo=; b=NyEUx7ym8YfQpqXeaVxaBucM+8qX1tuWjRb05h2oEyPiFL9QPrgYfZrapWiMTP2+le V3G2cS8P/+qnze+4KJfu7TFfIZSo57geZiBdpwJUlSn2R/esKiXw1jwCCx61ndqUhrm9 od2R9qtKj5WD04pI+aM64cVTvuKFlFjva4nMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=mxzBJxd42Q19eZ8TxGzKNBZXhBzaQU4IDaeRBDe1eth20JnSmqHlur50aXAPggJ9hK r6XIbbGg9hpcYi7k5kzwPaTpz5kwT1PWYdCGN59JKPD7dX5WvTVC5r02AwTLAj/DmdNV sIzZQR66y90G/mNIdklVWtb3OYHvkqc55ppAM= Received: by 10.14.17.194 with SMTP id j42mr2144632eej.81.1304708070020; Fri, 06 May 2011 11:54:30 -0700 (PDT) Received: from [192.168.1.138] (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id k32sm1556593eea.27.2011.05.06.11.54.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2011 11:54:28 -0700 (PDT) Sender: Ole Troan Subject: Re: Short 6MAN WG Last Call: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> Date: Fri, 6 May 2011 20:54:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: 6man Mailing List , Brian Haberman , Bob Hinden 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, 06 May 2011 18:54:33 -0000 Thomas, > Thanks for the review! >=20 >> I'm on the fence with regards to this document. if this document is >> meant to be the RFC1122/1812 document for IPv6, I think we are too >> early in the deployment of IPv6 to have gathered enough experience >> with what works and what doesn't. as a profile of an IPv6 node >> though, it isn't too far off. >=20 > As Bob says, this is a revision of an existing document. Its a much > more current set of recommendations than RFC 4294. please let me withdraw that comment. off the cuff remark. >> a couple of comments: >=20 >> * section 5.3. Default Router Preferences and More-Specific Routes - = RFC 4191 >> this is a "MAY wish" and in conflict with RFC6204, L-3. >> please make this a SHOULD or even a MUST (as hosts not supporting it = will not be able to interoperate on networks behind >> RFC6204 routers. >=20 > I'm not entirely sure what to do here. RFC 4191 is not widely > implemented, AFAIK. It's in Windows Vista (and onwards) and also > Linux. Not sure where else (I'm guessing not on Macs?) >=20 > So, I'm not at all sure we should recommend it as a SHOULD. IMO, its > not a crucial document, and its not widely implemented. >=20 > Can someone explain to me the rationale for mandating 4191 in 6204? > What was the scenario that was envisioned that necessitates 4191?=20 it was the only way we found to keep support for ULA prefixes. the scenario is if you have a home CPE with ULA enabled, but no upstream = IPv6 connectivity. if that router advertises itself as a router for default, as opposed to = router for ULA, host implementations that don't do 3484bis, and don't handle ICMPs, will contribute to IPv6 = breakage. e.g. 75 second time outs per TCP connection. >> * RFC2675: I would just remove that. >=20 > The docuent currently says: >=20 > IPv6 Jumbograms [RFC2675] MAY be supported. >=20 > How about I replace that with: >=20 > IPv6 Jumbograms [RFC2675] are an optional extension that allow > the sending of IP datagrams larger than 65.535 bytes. IPv6 > Jumbograms make use of IPv6 hop-by-hop options and are only > suitable on paths in which every hop and link are capable of > supporting Jumbograms (e.g., within a campus or datacenter). To > date, few implementations exist and there is essentially no > reported experience from usage. Consequently, IPv6 Jumbograms > [RFC2675] remain optional at this time. >=20 > (key change is "MAY" to just lower case "optional"). =20 I'm fine with that. the reason I brought it up is because we have people (aka customers) = asking us for support for this. and it has so far in every case been = either because of mixing it up with jumbo frames, or not understanding = what it is. >> * 5.9.4 Default Address Selection >> As RFC3484 generates IPv6 brokenness. I think we should change >> this reference to RFC3484bis. >=20 > Can't do that. That would delay publication of the RFC. >=20 > BTW, you could make the same arguement w.r.t. the Flow Label. And > possibly other things that are still in revision... while it isn't correct to say that rfc3484 contributes to IPv6 breakage, = I would very much like a reference to something that actually helps. is it urgent to get the node requirements document out? I thought = 3484-revise was quiet far along in the process. chairs? >> * 5.9.5. Stateful Address Autoconfiguration >> I still disagree with the MAY for DHCP. I don't think we should >> state the 'at the present time SLAAC'. >=20 > Note: full quote is: >=20 > At the present time, the configuration of stateless address > autoconfiguration is more widely implemented in hosts than > address configuration through DHCP. >=20 > This would appear to be statement of fact. (And on rereading it, I > would suggestion changing the sentence to:=20 >=20 > At the present time, the configuration of addresses via > stateless autoconfiguration is more widely implemented in hosts > than address configuration via DHCP. that statement will be true as long as there exists a single host on the = planet that doesn't do DHCPv6. assuming they all do SLAAC. ;-) >> hosts that cannot do DHCP for address assignment may not be able >> to connect to many cable networks (see DOCSIS 3) >=20 > Is this true for *end user* hosts at behind a DOCSYS modem? I believe > not.=20 yes, it is. a DOCSIS modem is a bridge. with a router it is OK = obviously. >> and access networks specified by the BBF. >=20 > IMO, the day of having CPE devices support bridging are gone. It is > perfectly fine to require the use of a router rather than allowing end > clients to connect directly. Such routers could be required to > implement DHC. But you can't reasonably expect all client end devices > to support it. We missed the boat on that years ago. I disagree. the consequence is that hosts that not support DHCP, will just not get = service. that's pretty bad, and I think the prudent approach would be to have = SLAAC as a MUST and stateful as a SHOULD. after all you have the following text that states: "However, some environments may require the use of DHCP and may not = support the configuration of addresses via RAs." that is a pretty severe interoperability problem. I'm happy that 6106 is a SHOULD, but if you are looking for = implementations for that option you have to look very hard "at the = present time". basically I want the document to say that IETF has standardised two = mechanisms to configure hosts. one using ND and one using DHCP. as they = apply to different management models, nodes SHOULD implement both. (and = add suitable apologies to the world for having messed this up badly. = ;-)) >> * 6 DHCP vs. Router Advertisement Options for Host Configuration >> I don't understand the purpose of this section. >=20 > It is a bit of history/background. I would be happier if it included text stating the above. >> it should include text explaining how to handle conflicts between > multiple mechanisms if anything. >=20 > The existing specifications already address this. This document has > nothing to add. does it in the general case? i.e. that if you get one address from SLAAC and one from DHCPv6 the = result is two addresses. same with DNS options and so on. do you have a reference? >> and make it clear that every node has to implement all >> mechanisms. that's the natural consequence of designing multiple >> ways of doing the same thing. >=20 > The WG has not been willing to do that. Unless something has changed > recently, I do not see support for elevating DHC support beyond MAY > (for addresses anyway). we are making solutions depending on DHCP support: draft-ietf-mif-dhcpv6-route-option draft-ietf-6man-addr-select-opt ... >> * 8.1. Transition Mechanisms >> Just remove the section. it doesn't add value. >=20 > I agree there isn't much there, but for completeness, I think it > should stay. OK. >> * 12.1.1 Router Alert >> not just acknowledge that the HBH option was a bad idea and nuke it? >=20 > Not sure what your point is here. HBH options are mandatory to > implement at this time. Way to late to deprecate them. Neighbor > Discovery depends on it (i.e., MLD mandates it, and you need MLD for > ND). if ipv6->next_header =3D=3D 0 plonk ? OK, I will not argue the point further. packets with HBH headers will be = severely rated limited anyway... cheers, Ole From john.loughney@nokia.com Fri May 6 12:15: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 65EA1E0709 for ; Fri, 6 May 2011 12:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 muvNOTlLNRhQ for ; Fri, 6 May 2011 12:15:43 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id C1343E067A for ; Fri, 6 May 2011 12:15:42 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p46HsfWY009451; Fri, 6 May 2011 20:54:42 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 May 2011 20:54:41 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 6 May 2011 19:54:41 +0200 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.183]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0289.008; Fri, 6 May 2011 19:54:40 +0200 From: To: , Subject: RE: Short 6MAN WG Last Call: Thread-Topic: Short 6MAN WG Last Call: Thread-Index: AQHMBouUVucckJc8M0CGOJDun35LeJR+J8SAgAHVL4CAACJC0A== Date: Fri, 6 May 2011 17:54:39 +0000 Message-ID: <1571128F4B736C42B743F492521F123B1E1F0D@008-AM1MPN1-003.mgdnok.nokia.com> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> In-Reply-To: <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.243.186.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 May 2011 17:54:41.0649 (UTC) FILETIME=[ACE64E10:01CC0C16] X-Nokia-AV: Clean Cc: bob.hinden@gmail.com, brian@innovationslab.net, 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, 06 May 2011 19:15:44 -0000 Thomas, One small comment and one small nit, inline: > > * 5.9.4 Default Address Selection > > As RFC3484 generates IPv6 brokenness. I think we should change > > this reference to RFC3484bis. > > Can't do that. That would delay publication of the RFC. >=20 > BTW, you could make the same arguement w.r.t. the Flow Label. And possibl= y other things that are still in revision... COMMENT: I think we have general agreement in the WG that IPv6 will still b= e evolving for some time, and we fully expect that more updates to the Node= Requirements will be needed, so waiting for all changes would be pointless= . > > * 5.9.5. Stateful Address Autoconfiguration > > I still disagree with the MAY for DHCP. I don't think we should > > state the 'at the present time SLAAC'. >=20 > Note: full quote is: >=20 > At the present time, the configuration of stateless address > autoconfiguration is more widely implemented in hosts than > address configuration through DHCP. > > This would appear to be statement of fact. (And on rereading it, I would = suggestion changing the sentence to:=20 >=20 > At the present time, the configuration of addresses via > stateless autoconfiguration is more widely implemented in hosts > than address configuration via DHCP. NIT: Would it make sense to change "At the present time, ..." with "At the = time of publication of this document, ..." Otherwise, I agree with your comments. John From Wesley.E.George@sprint.com Fri May 6 12:52:31 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 0EF76E07D6 for ; Fri, 6 May 2011 12:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.437 X-Spam-Level: X-Spam-Status: No, score=-5.437 tagged_above=-999 required=5 tests=[AWL=1.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 rcG-BuOx8zoA for ; Fri, 6 May 2011 12:52:30 -0700 (PDT) Received: from VA3EHSOBE009.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 19CF3E0775 for ; Fri, 6 May 2011 12:52:29 -0700 (PDT) Received: from mail193-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.8; Fri, 6 May 2011 19:52:28 +0000 Received: from mail193-va3 (localhost.localdomain [127.0.0.1]) by mail193-va3-R.bigfish.com (Postfix) with ESMTP id 1CC31AC83AD; Fri, 6 May 2011 19:52:27 +0000 (UTC) X-SpamScore: -12 X-BigFish: VS-12(zz9371O542Mzz1202hzzz2fh2a8h668h839h34h62h) X-Spam-TCS-SCL: 1:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI Received: from mail193-va3 (localhost.localdomain [127.0.0.1]) by mail193-va3 (MessageSwitch) id 1304711529138590_19379; Fri, 6 May 2011 19:52:09 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.246]) by mail193-va3.bigfish.com (Postfix) with ESMTP id C455D1B30133; Fri, 6 May 2011 19:50:37 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 6 May 2011 19:50:35 +0000 Received: from PLSWEH03.ad.sprint.com (PLSWEH03.corp.sprint.com [144.226.242.132]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p46JoXbZ014080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 May 2011 14:50:33 -0500 Received: from PDAWEH04.ad.sprint.com (144.226.111.59) by PLSWEH03.ad.sprint.com (144.226.242.132) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 6 May 2011 14:50:33 -0500 Received: from PDAWM12B.ad.sprint.com ([fe80::64c8:fd69:1029:79b0]) by PDAWEH04.ad.sprint.com ([2002:90e2:6f3b::90e2:6f3b]) with mapi id 14.01.0270.001; Fri, 6 May 2011 14:50:33 -0500 From: "George, Wes E [NTK]" To: Thomas Narten Subject: RE: Flow label drafts updated Thread-Topic: Flow label drafts updated Thread-Index: AQHMC/FN7fSFLcsbkk6qh9NN16/5HJSAB6ow Date: Fri, 6 May 2011 19:50:31 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C90694@PDAWM12B.ad.sprint.com> References: <4DC07A80.2030200@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> <201105061326.p46DQksH014118@cichlid.raleigh.ibm.com> In-Reply-To: <201105061326.p46DQksH014118@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.57] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_006F_01CC0C05.53DACDC0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "ipv6@ietf.org" , RJ Atkinson , Brian E Carpenter 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, 06 May 2011 19:52:31 -0000 ------=_NextPart_000_006F_01CC0C05.53DACDC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Friday, May 06, 2011 9:27 AM Subject: Re: Flow label drafts updated Is the UDP port number mutable? Is the TCP sequence number immutable? [WEG] I think both are immutable because there's a checksum to detect changes. That doesn't make it impossible to change it in the middle, as you mention, but it makes it much less likely that it will be. There are ways of modifying them that are undetecable. Does that make them mutable? [WEG] Would you write similar language into the TCP and UDP spec like this that claims immutable but that implementers should assume that it'll be changed along the way? By my interpretation, it comes down to level of risk for modification. IMO the checksum is a significant difference and means that there is a reasonable assumption that things won't be changed along the way. At the very least it'll detect changes due to data corruption, which you can't say for the IPv6 header. The intention is that the Flow Label not get modified. Doing so can impact its usefulness. This is true of most fields in packets. If random actors start tweaking various fields in a packet, that tends to not be helpful (or worse). [WEG] Absolutely agree, but I don't think that calling it immutable is the only way to say it, especially if you bracket it with a qualifier that says it's likely to get changed anyway. I do think the document needs to say something about covert channels and border routers zeroing out the field (and not just stick its head in the sand and try to have it both ways, which the wording Wes quoted effectively does). But that doesn't mean we are declaring that the field is "mutable", implying that anyone can start doing with it what they want. [WEG] fair enough, but I think this is sort of like the line between MUST NOT and SHOULD NOT. What you're saying here is you SHOULD NOT change the value, while acknowledging that it's likely to happen in certain applications. To me, Immutable implies MUST NOT be changed, and while people may still ignore MUSTs it's less likely. To me, "anyone can start doing what they want" implies a MAY be changed Wes George ------=_NextPart_000_006F_01CC0C05.53DACDC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwNjE5 NTAzMFowIwYJKoZIhvcNAQkEMRYEFACS18ZFSHlQ7DLy+BTok/TLpm73MFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgA2PoV4GvGq3YAivvP7rOjJn/Jl9W7t8uu3UMzhLogvyQDEUvKOmavo8xrf/GCAG1TMk ATFsFa0r5aVTA0vhWf7fupxIq2kBF6J85TKQdUqVNe2KjxAsdY75Tfckac14zSBvYApRlLK7SghA CQlPXzd3YeS6HFKRqDQ566J1YQ9dAAAAAAAA ------=_NextPart_000_006F_01CC0C05.53DACDC0-- From brian.e.carpenter@gmail.com Fri May 6 18:13: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 47161E06B0 for ; Fri, 6 May 2011 18:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.352 X-Spam-Level: X-Spam-Status: No, score=-103.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 xXVsNL3ID9bE for ; Fri, 6 May 2011 18:13:01 -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 54B3FE0676 for ; Fri, 6 May 2011 18:13:01 -0700 (PDT) Received: by bwz13 with SMTP id 13so3361331bwz.31 for ; Fri, 06 May 2011 18:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sUKYBHmQOX9JYdCsJJRROw+hhmfBW91Vzba4h/UXBMU=; b=kcqgOwyDlxiFbbdxuEy4vCX8IC9F0zLKaFq7K08+A7xUyDtZmLQSLBr54pLLfexNwU y/CeQ2vQHFGtqkxrp25RJU4dpuT9FRzns/tqRqRDDsBBKhVbvC3LBjsHEYKDxUFMcN59 x+5e49evJMFnnHk+SQ6mxvr5fWTmIrc1+BD8c= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=nuuigfvNmIgBWoSHGwxNqtkgEDlyN7FSwxKY7ZPydWXpizw3OuFYLBhVU7YflzFA97 QGuUREmNL1wlMMxuMAzX9SaPNec3agPqm9MCb/5vUyCkeXfcuB9bZbRSsQEaCPmqwOHX xk4942JEdfj0mTKE6juD6Waq8n1330CSG9GIs= Received: by 10.204.19.10 with SMTP id y10mr100246bka.190.1304730780413; Fri, 06 May 2011 18:13:00 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id c11sm2310129bkc.14.2011.05.06.18.12.56 (version=SSLv3 cipher=OTHER); Fri, 06 May 2011 18:12:59 -0700 (PDT) Message-ID: <4DC49C90.9060605@gmail.com> Date: Sat, 07 May 2011 13:12:48 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: Flow label drafts updated References: <4DC07A80.2030200@gmail.com> <09C574A2-37D4-4507-A3F8-9B68F95FAE16@gmail.com> In-Reply-To: <09C574A2-37D4-4507-A3F8-9B68F95FAE16@gmail.com> Content-Type: text/plain; charset=UTF-8 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: Sat, 07 May 2011 01:13:02 -0000 Ran, I'm obliged to repeat myself: there has been endless feedback in the WG that the flow label remains defined as immutable, so any middlebox that changes it is violating the standard. Of course the chairs can tell me this is now an open issue, but we have been over it many times. Regards Brian On 2011-05-06 00:55, RJ Atkinson wrote: > On 03 May 2011, at 17:58 , Brian E Carpenter wrote: >>> and also the apparent decision to write these documents >>> in a manner intended to legislate reasonable security measures >>> (if applicable only in selected deployments) out of existence. >> I don't understand this comment. The flow label has always been >> defined as immutable; the consensus in the WG is to keep that >> property. So a firewall that overwrites it is unambiguously >> breaking the standard. > > > Brian, > > The flow label has been modified by routers/security gateways > for many years now. It is not a new event. I was first aware > of it circa 1997. As near as I can tell, this has been done > for security reasons the whole time. Those security reasons > are in fact reasonable, albeit not applicable to all environments. > > Pretending those legitimate security considerations don't exist > is actively harmful, which is why the operational practice is > not new. IPv6 specifications should reflect reality, > not a theoretical world that we know does not exist > (and never has, or at least hasn't existed for ~15 years now). > > I proposed edits that are reasonable. This WG has not > considered those edits. It is not obvious to me that > there is any consensus, either way, on the current > wording or on the proposed wording. There should be > further WG discussion if you really believe the proposed > edit is technically unsoundl, otherwise the edit ought > to be made (or a wordsmithed version of it). > > Yours, > > Ran > > From brian.e.carpenter@gmail.com Fri May 6 18:23: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 C6844E0676 for ; Fri, 6 May 2011 18:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.37 X-Spam-Level: X-Spam-Status: No, score=-103.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 M3Iwhc5dcGW4 for ; Fri, 6 May 2011 18:23:29 -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 E5F9FE064B for ; Fri, 6 May 2011 18:23:28 -0700 (PDT) Received: by bwz13 with SMTP id 13so3364858bwz.31 for ; Fri, 06 May 2011 18:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5VIBMor0XUf1+lbUgTwzSwbLw9u2b7XVkhVx7QvKFzU=; b=A69sqQcK7aw0BavE5PMKd6DJI2v2R1aBNlL1F2Lm1Ol1+07mBuDc0Ep5EC1+MEcdMi G4f1nYoDE0hWuV9B9SSQZAy9A+4I32jsLefAq5TvFimQS8a+1Dk4/TraEbLPx6Hw511G xkeT5PNjliPOEKQgI9QatiSYET+LVRZBaQPh0= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=YH4xUZ9rvzcpbRriZPg99L+71b+5DNI8gsaHkuBCzxSInLJ2mAzUUDZe9ji//CdS/Y trAbcAp4jM8nt8KGevkcFcUULG8z4YabraIHS5YenGdJ4w8PT1oNy4WPKcPWpBUcKA7/ 7i3d4ks4giQZvYqqpuAk6nGVuVJWm3dyVV+XE= Received: by 10.204.75.22 with SMTP id w22mr569081bkj.65.1304731407954; Fri, 06 May 2011 18:23:27 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id q24sm2315912bks.9.2011.05.06.18.23.23 (version=SSLv3 cipher=OTHER); Fri, 06 May 2011 18:23:27 -0700 (PDT) Message-ID: <4DC49F04.40900@gmail.com> Date: Sat, 07 May 2011 13:23:16 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "George, Wes E [NTK]" Subject: Re: Flow label drafts updated References: <4DC07A80.2030200@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> <201105061326.p46DQksH014118@cichlid.raleigh.ibm.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C90694@PDAWM12B.ad.sprint.com> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C90694@PDAWM12B.ad.sprint.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , RJ Atkinson , "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: Sat, 07 May 2011 01:23:29 -0000 below... On 2011-05-07 07:50, George, Wes E [NTK] wrote: > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Friday, May 06, 2011 9:27 AM > Subject: Re: Flow label drafts updated > > Is the UDP port number mutable? Is the TCP sequence number immutable? > [WEG] I think both are immutable because there's a checksum to detect changes. That doesn't make it impossible to change it in the > middle, as you mention, but it makes it much less likely that it will be. > > There are ways of modifying them that are undetecable. Does that make them mutable? > [WEG] Would you write similar language into the TCP and UDP spec like this that claims immutable but that implementers should assume > that it'll be changed along the way? By my interpretation, it comes down to level of risk for modification. IMO the checksum is a > significant difference and means that there is a reasonable assumption that things won't be changed along the way. At the very least > it'll detect changes due to data corruption, which you can't say for the IPv6 header. > > The intention is that the Flow Label not get modified. Doing so can impact its usefulness. This is true of most fields in packets. > If random actors start tweaking various fields in a packet, that tends to not be helpful (or worse). > [WEG] Absolutely agree, but I don't think that calling it immutable is the only way to say it, especially if you bracket it with a > qualifier that says it's likely to get changed anyway. > > I do think the document needs to say something about covert channels and border routers zeroing out the field (and not just stick > its head in the sand and try to have it both ways, which the wording Wes quoted effectively does). > But that doesn't mean we are declaring that the field is "mutable", implying that anyone can start doing with it what they want. > [WEG] fair enough, but I think this is sort of like the line between MUST NOT and SHOULD NOT. > What you're saying here is you SHOULD NOT change the value, while acknowledging that it's likely to happen in certain applications. It's the first I've heard of it. You MUST NOT change addresses and port numbers in a packet; not that RFC 791 and 793 bother to mention it, because it was unimaginable in 1981 that anyone except an attacker would do such a thing. I'm hard over on a MUST NOT. What we've been arguing with Thomas is really about how to express the warning that the flow label might get undetectably changed by an on-path device, even though that is against the standard. A node downstream from the change can't tell that it was changed, whether maliciously or by a misguided firewall. Brian > To me, Immutable implies MUST NOT be changed, and while people may still ignore MUSTs it's less likely. > To me, "anyone can start doing what they want" implies a MAY be changed > > Wes George > > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From rja.lists@gmail.com Sat May 7 04:38: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 B1CA5E06DA for ; Sat, 7 May 2011 04:38:57 -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, RCVD_IN_DNSWL_LOW=-1] 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 HOEo1c8aaQtL for ; Sat, 7 May 2011 04:38:56 -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 72C0AE0663 for ; Sat, 7 May 2011 04:38:56 -0700 (PDT) Received: by vxg33 with SMTP id 33so5148340vxg.31 for ; Sat, 07 May 2011 04:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=0i+gT9em04fEjGjKJp/+7msBoWB86iBL1lE0rQxAhIE=; b=XA1STp3itTMi7GFeVl5iB2tcoIZVh+x72E6zP6xcHzvNfyewqG4Gd7CmxbNr9LglpD KM0kuD6LDesH+JHb7cAgv3wOcfmzkBo+5/uL6qkFlpMMmDGm8DxDvFZoJJwRvWxjRj95 D5D2UkTpf4/CUY2illVrgsZwAViwAIoF+Eikc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=nTowYf0ShppJ6AIOhjshcTiN7sRPGJHimw6ehs+2bssw6fnp35s2Jmt9rvQy+5z5p+ DJUth4jc2+msSHcULwvoKvMCMW6MplBBCW/TOvZ42fQ2ItrCPY9AKuTOlEx/0bVbBraH 0gcGAcBIfgcaYG/Rne3B64QBdsc23CFHujVkA= Received: by 10.52.71.70 with SMTP id s6mr1203431vdu.80.1304767999671; Sat, 07 May 2011 04:33:19 -0700 (PDT) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id b10sm585869vdw.38.2011.05.07.04.33.17 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 07 May 2011 04:33:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: Flow label drafts updated From: RJ Atkinson In-Reply-To: <4DC49F04.40900@gmail.com> Date: Sat, 7 May 2011 07:33:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DC07A80.2030200@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> <201105061326.p46DQksH014118@cichlid.raleigh.ibm.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C90694@PDAWM12B.ad.sprint.com> <4DC49F04.40900@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1084) 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, 07 May 2011 11:38:57 -0000 On 06 May 2011, at 21:23 , Brian E Carpenter wrote: > I'm hard over on a MUST NOT. What we've been arguing with Thomas is = really about > how to express the warning that the flow label might get undetectably = changed by > an on-path device, even though that is against the standard. A node = downstream > from the change can't tell that it was changed, whether maliciously or > by a misguided firewall. Brian, As Wes and others (including me) have been pointing out is that the IPv6 specs have been ambiguous about the Flow Label field for a very = long=20 time (i.e. including before this current set of I-Ds). The specs have=20= tried simultaneously both to discourage modification of the Flow Label=20= field (which I believe everyone agrees is strongly desirable in normal=20= circumstances) and simultaneously recognising that the field might be=20 changed (i.e. in some other circumstances). This issue is very far from new. As the AH designer/author, I can say that the reason AH doesn't include the Flow Label field in its integrity checks is that network operators (a term I use to mean *anyone* who = operates any network, whether service provider, content provider, home network,=20= enterprise network, educational network, or other network) way back=20 in the early 1990s were clear that in some circumstances the Flow Label=20= field would be changed during transit. The IPv6 WG was comfortable with that at the time. =20 Further, other IETF standards-track specifications (e.g. RFC-2402,=20 Section 3.3.3.1.2.1; RFC-4302, Section 3.3.3.1.2.1) clearly note the=20 IPv6 Flow Label as "mutable". RFC-1886 Section 6 and RFC-2460 Section 6=20= both require that hosts/routers *that do not support the Flow Label*=20 not modify it, but does NOT require that hosts/routers that do support=20= the Flow Label not modify its value. RFC-4302 specifically notes that=20= RFC-2460 does permit modification of the IPv6 Flow Label. The Security=20= Gateways I've been talking about clearly DO support the Flow Label,=20 so are NOT covered by that prohibition. It is only with RFC-3697 that an attempt is made to prohibit modification of the Flow Label in transit -- but of course there are a number of IPv6 devices deployed that pre-date that specificatio. Further, RFC-3697 does NOT claim to update RFC-2460 (and RFC-2460 does allow=20 modification). =20 So there is an inherent ambiguity in the set of IETF standards-track=20= specifications on this topic. It is also quite clear the IPv6 WG=20 does NOT have some sort of long-standing agreement that this practice=20 should be prohibited; instead the long-standing situation is that change=20= should be strongly discouraged (i.e. SHOULD NOT), but is both expected=20= and tolerated in the (few) situations where it is necessary from an operational security perspective. Your assertion that a firewall modifying the Flow Label field is=20 "misguided" is not technically sound. In some deployment situations,=20 rewriting the Flow Label field (e.g. from some received value which might contain covert information to some different value which the security gateway determines does not contain covert information)=20 is the only technically sound behaviour. Those situations are not=20 numerous, fortunately. I find it curious that you aren't addressing the technical issues that various folks are raising here, instead solely talking about legalistic claims. If you have a concrete technical issue,=20 please put it forward and lets discuss it. It is also wrong to try to separate this concern from Thomas Narten's concern as they are quite closely related and inter-twined. Yours, Ran Atkinson From brian.e.carpenter@gmail.com Sun May 8 16:06:31 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 3E0BDE0729 for ; Sun, 8 May 2011 16:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.49 X-Spam-Level: X-Spam-Status: No, score=-103.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 E4mBnXl3ojL0 for ; Sun, 8 May 2011 16:06:30 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 85E46E06B1 for ; Sun, 8 May 2011 16:06:29 -0700 (PDT) Received: by pvh1 with SMTP id 1so2865195pvh.31 for ; Sun, 08 May 2011 16:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dlJINgcFgsFAhvjpu/34uTCFbup5NEax/7RBijsLYTc=; b=iP21Fjwqood7ZZAEVsb1dOUQb2fFjLp5RArujNjIaMnxFp6glxqxheFtcBwaC1AKU4 qdYPpvFiNYbWIdWq1rQ4Ar/2jRlBeqSi15PciPQS+hOOEBd7i6VwJCFkMcMJnv902Ao7 CxH5GoXOdoTEno1OOP7HgX5KRnsp88EZhx+Ag= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Y9dtsdsgroW5tr+63UvXx8Y1PWE8M1dViVCtdz3g1/R+G5CNipctUNK458SCTjsXf/ snZpMa2uHPso7H9kIwvidmvc5ivH6wJXEM24VwjsSHrZ2HMUHUn8fawLrG3Nhj1V1kde 784fFCuBM0xOUgQa3Y5O9zNY0QOufwnhes+Ps= Received: by 10.68.7.132 with SMTP id j4mr9028354pba.463.1304895989412; Sun, 08 May 2011 16:06:29 -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 n4sm3687990pbj.97.2011.05.08.16.06.26 (version=SSLv3 cipher=OTHER); Sun, 08 May 2011 16:06:27 -0700 (PDT) Message-ID: <4DC721EF.70002@gmail.com> Date: Mon, 09 May 2011 11:06:23 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "George, Wes E [NTK]" Subject: Re: Flow label drafts updated References: <4DC07A80.2030200@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , RJ Atkinson 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, 08 May 2011 23:06:31 -0000 Wes, Let me focus on one phrase of yours: > because no implementer in their right mind is going to try > to use this for an application that needs the label to be immutable in all cases. Correct, and that has always been the case, even for any hypothetical implementers of RFC 3697. The difference is that we're trying to say it more clearly in 3697bis, and obviously haven't quite succeeded yet. Nodes MUST NOT change the flow label. But since you can't detect whether it's been changed, mechanisms using the flow label for some purpose must be robust against unanticipated changes. What that means in the stateless load-balancing model is that the impact of a changed value needs to be limited to sub-optimal load balancing. What it means in other, hypothetical, models for using the flow label I cannot say. It's for the designer of such a model to figure out. Maybe it's just the use of the word "immutable" that is causing the problem here, because it implies something that physically isn't true. Regards Brian On 2011-05-06 01:48, George, Wes E [NTK] wrote: > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter > Sent: Tuesday, May 03, 2011 5:58 PM > Subject: Re: Flow label drafts updated > >> and also the apparent decision to write these documents in a manner >> intended to legislate reasonable security measures (if applicable only >> in selected deployments) out of existence. > > I don't understand this comment. The flow label has always been defined as immutable; the consensus in the WG is to keep that > property. So a firewall that overwrites it is unambiguously breaking the standard. > > [WEG] now it's my turn to be confused by your comment, Brian. I missed this detail of interpretation when reviewing the draft for > LC, and I apologize, but I think it's pretty important... >>From the 3697bis draft: > "There is no way to verify whether a flow label has been modified en > route or whether it belongs to a uniform distribution. Therefore, no > Internet-wide mechanism can depend mathematically on immutable and > uniformly distributed flow labels; they have a "best effort" quality." > But it goes on to say: > " This specification defines the flow label as immutable once it has > been set to a non-zero value. However, implementers are advised that > forwarding nodes, especially those acting as domain border devices, > might nevertheless be configured to change the flow label value in > packets. This is undetectable." > My interpretation of the above is that it functionally renders the flow label mutable. If one cannot assume that the flow label will > arrive at its destination with the original value intact, nor detect when it has been changed, it is by definition mutable and it's > nonsensical to have this discussed in such an ambiguous way in the draft, because no implementer in their right mind is going to try > to use this for an application that needs the label to be immutable in all cases. This draft should be correcting the fundamentally > flawed assumption that an unprotected field can be immutable. I don't see how Ran's comments would be a different case and > (apparently) a different interpretation of the above. > > I don't recall consensus forming around this idea of immutable, but with asterisks instead of simply acknowledging that regardless > of what the standard said before, the label has always been mutable since it's unprotected. However, I've had a couple of gaps where > $day_job has taken precedence over IETF lists, so I might have missed a part of that discussion. Apologies if I'm rehashing. Perhaps > the chairs would like to offer an interpretation? > > Wes George From albert.e.manfredi@boeing.com Sun May 8 16:49: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 96725E0794 for ; Sun, 8 May 2011 16:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 OZzOrd9EzSO8 for ; Sun, 8 May 2011 16:49:32 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id ED8CAE0684 for ; Sun, 8 May 2011 16:49:31 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p48NLiQa002990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 8 May 2011 16:21:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p48NLiJo019177 for ; Sun, 8 May 2011 16:21:44 -0700 (PDT) Received: from XCH-MWHT-05.mw.nos.boeing.com (xch-mwht-05.mw.nos.boeing.com [134.57.119.160]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p48NLc3i018921 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 8 May 2011 16:21:39 -0700 (PDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-05.mw.nos.boeing.com ([134.57.119.160]) with mapi; Sun, 8 May 2011 18:21:38 -0500 From: "Manfredi, Albert E" To: Brian E Carpenter Date: Sun, 8 May 2011 18:21:35 -0500 Subject: RE: Flow label drafts updated Thread-Topic: Flow label drafts updated Thread-Index: AcwN1NgtvUBZwao5RkWmIbhXxVM5YwAAPquA Message-ID: References: <4DC07A80.203020 0@gmail.com><54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> <4DC721EF.70002@gmail.com> In-Reply-To: <4DC721EF.70002@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 08 May 2011 23:49:32 -0000 Brian E Carpenter wrote: > Nodes MUST NOT change the flow label. But since you can't detect > whether > it's been changed, mechanisms using the flow label for some purpose > must > be robust against unanticipated changes. If I may try to express what I perceive the problem to be, we have been tol= d that (for example, and there may be others) certain security gateways DO = change the value of that FL. And presumably, for good security-minded reaso= ns. So to say FL MUST NOT be changed is, I gather, factually not possible a= nymore. I agree that "since you can't detect whether it's been changed, mechanisms = using the flow label for some purpose must be robust against unanticipated = changes," however I think the hard nut is this MUST NOT be changed requirem= ent. So for example, the load balancing use of FL must not cause the session to = break if FL has been changed. Bert From brian.e.carpenter@gmail.com Sun May 8 16:55: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 9D421E0684 for ; Sun, 8 May 2011 16:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.493 X-Spam-Level: X-Spam-Status: No, score=-103.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 hq7dFIUEkrcM for ; Sun, 8 May 2011 16:55:43 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id B5E1DE067A for ; Sun, 8 May 2011 16:55:43 -0700 (PDT) Received: by pxi2 with SMTP id 2so2913708pxi.38 for ; Sun, 08 May 2011 16:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=38k851tWOlis3roBUDJ+loj2kxWfDmEgQPN3uDEerV4=; b=MeSjE3m5QRSxSXSujIQeFBWYH8foAjp+7QAy4UpBZXBNoqa84ogcrCo/4AvKeOUPcu N4K7HmKVDZiC1OazX5Xgrfl113edaVw3u+naILQcZLk8mcp2rJCWOVKC4Zlq6w/2jvXf MMgLft2PHaTaCuoeDVJsqqvObz+hjCTOwkQ/0= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=MWNDLe8JAJd8/eOMf4FfmInL56AN4fnRl/7s4TwiPDDpaBtrnl+r9x+/dq9XMEo+eA igjz3bgNMFi83xFKd1tkIYg05cPZ+BSAuUwnr7+IQKzJbeGDwtlbVxQwZbrlwigqcBrT mcLW0AuKpgf2RjgmKng9p7G+ZtZvoPcg90+EI= Received: by 10.68.59.71 with SMTP id x7mr9156263pbq.105.1304898480970; Sun, 08 May 2011 16:48:00 -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 l9sm2681875pbc.14.2011.05.08.16.47.59 (version=SSLv3 cipher=OTHER); Sun, 08 May 2011 16:48:00 -0700 (PDT) Message-ID: <4DC72BAD.7020007@gmail.com> Date: Mon, 09 May 2011 11:47:57 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: Flow label drafts updated References: <4DC07A80.2030200@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> <201105061326.p46DQksH014118@cichlid.raleigh.ibm.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C90694@PDAWM12B.ad.sprint.com> <4DC49F04.40900@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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, 08 May 2011 23:55:44 -0000 On 2011-05-07 23:33, RJ Atkinson wrote: > On 06 May 2011, at 21:23 , Brian E Carpenter wrote: >> I'm hard over on a MUST NOT. What we've been arguing with Thomas is really about >> how to express the warning that the flow label might get undetectably changed by >> an on-path device, even though that is against the standard. A node downstream >> from the change can't tell that it was changed, whether maliciously or >> by a misguided firewall. > > Brian, > > As Wes and others (including me) have been pointing out is that the > IPv6 specs have been ambiguous about the Flow Label field for a very long > time (i.e. including before this current set of I-Ds). The specs have > tried simultaneously both to discourage modification of the Flow Label > field (which I believe everyone agrees is strongly desirable in normal > circumstances) and simultaneously recognising that the field might be > changed (i.e. in some other circumstances). IMHO, RFC 3697 is quite clear that the flow label must not be modified, but quite unhelpful in discussing how to deal with the fact that it isn't checksummed. What RFC 2460 says about the flow label is pretty useless on all counts, which is why we wrote RFC 3697 in the first place. > > This issue is very far from new. As the AH designer/author, I can say > that the reason AH doesn't include the Flow Label field in its integrity > checks is that network operators (a term I use to mean *anyone* who operates > any network, whether service provider, content provider, home network, > enterprise network, educational network, or other network) way back > in the early 1990s were clear that in some circumstances the Flow Label > field would be changed during transit. The IPv6 WG was comfortable > with that at the time. I take your word for it, but when the WG did RFC 3697 in 2003/2004, there was strong consensus for the immutability rule. > > Further, other IETF standards-track specifications (e.g. RFC-2402, > Section 3.3.3.1.2.1; RFC-4302, Section 3.3.3.1.2.1) clearly note the > IPv6 Flow Label as "mutable". There was a thread about this on the IPv6 WG list in September 2004, under the subject "AH and flow label". The conclusion was to continue to leave the flow label out of the ICV calculation in the AH update that became RFC 4302, although it was by then clearly specified as immutable by RFC 3697. It seemed that the goal was to be backwards compatible with RFC 2402. The terminology "immutable" and "mutable" was the only way in that RFC to tag header fields as included or excluded in the ICV calculation. So an immutable field (under RFC 3697) is labelled mutable in RFC 4302. Duh! RFC-1886 Section 6 and RFC-2460 Section 6 > both require that hosts/routers *that do not support the Flow Label* > not modify it, but does NOT require that hosts/routers that do support > the Flow Label not modify its value. RFC-4302 specifically notes that > RFC-2460 does permit modification of the IPv6 Flow Label. I missed that. It's a bug, since the correct normative reference at that time was RFC 3967. The Security > Gateways I've been talking about clearly DO support the Flow Label, > so are NOT covered by that prohibition. It is only with RFC-3697 > that an attempt is made to prohibit modification of the Flow Label > in transit -- but of course there are a number of IPv6 devices > deployed that pre-date that specificatio. Further, RFC-3697 > does NOT claim to update RFC-2460 (and RFC-2460 does allow > modification). 3697 clearly should have been tagged as formally updating 2460. 3697bis will definitely fix this. But it's really playing with words to assert that a firewall which chooses to overwrite the field is "supporting" it in the sense intended by the phrase "Hosts or routers that do not support the functions of the Flow Label field...". > So there is an inherent ambiguity in the set of IETF standards-track > specifications on this topic. It is also quite clear the IPv6 WG > does NOT have some sort of long-standing agreement that this practice > should be prohibited; IPv6 and its successor 6MAN have been very clear on this since 2003/4 when RFC 3697 was developed. instead the long-standing situation is that change > should be strongly discouraged (i.e. SHOULD NOT), but is both expected > and tolerated in the (few) situations where it is necessary from an > operational security perspective. So far, the guidance from the WG has been for a MUST NOT. Obviously, if the consensus changes, so will the draft. > Your assertion that a firewall modifying the Flow Label field is > "misguided" is not technically sound. In some deployment situations, > rewriting the Flow Label field (e.g. from some received value which > might contain covert information to some different value which the > security gateway determines does not contain covert information) > is the only technically sound behaviour. Those situations are not > numerous, fortunately. "Misguided" was an emotional choice of word, for which I apologise. I agree that there should be a discussion of covert channels in the Secutity Considerations of 3697bis. That is a clear omission. > > I find it curious that you aren't addressing the technical issues > that various folks are raising here, instead solely talking about > legalistic claims. What I'm talking about is what I think we heard from the WG over the past many months. If you have a concrete technical issue, > please put it forward and lets discuss it. The technical issue is that load balancing based on flow label values won't work properly if middleboxes (or attackers) change the values arbitrarily. It is also wrong to try > to separate this concern from Thomas Narten's concern as they are > quite closely related and inter-twined. Thomas has argued that if the label MUST NOT be changed, we should remove any suggestion of cases in which it's OK to change it. Followed to its logical conclusion, that means it's not OK for a firewall to change it. Brian From jmh@joelhalpern.com Sun May 8 17:09:03 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 AE016E0742 for ; Sun, 8 May 2011 17:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 XEe+W0WYNWze for ; Sun, 8 May 2011 17:08:59 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D5A64E0735 for ; Sun, 8 May 2011 17:08:59 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by morbo.tigertech.net (Postfix) with ESMTP id 4C162A3D23 for ; Sun, 8 May 2011 17:02:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id A32BD3244E33; Sun, 8 May 2011 17:02:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.10.194] (64-181-42-133.unassigned.ntelos.net [64.181.42.133]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 5732F32447BE; Sun, 8 May 2011 17:02:33 -0700 (PDT) Message-ID: <4DC72F0F.4010107@joelhalpern.com> Date: Sun, 08 May 2011 20:02:23 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: Flow label drafts updated References: <4DC07A80.203020 0@gmail.com><54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> <4DC721EF.70002@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Brian E Carpenter 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, 09 May 2011 00:09:03 -0000 I rather hate the following idea, and I am not sure that security gateways would be willing to follow it. In order for flow label usage to actually help the ECMP hardware, we have to expect it to work. What if security gateways were expected to put reasonable, flow distributing, flow -labels on their packets? Put differently, what if security gateways were behaving as if the received flow label were 0, and they were responsible for adding flow labels as the spec allows? Yours, Joel On 5/8/2011 7:21 PM, Manfredi, Albert E wrote: > Brian E Carpenter wrote: > >> Nodes MUST NOT change the flow label. But since you can't detect >> whether >> it's been changed, mechanisms using the flow label for some purpose >> must >> be robust against unanticipated changes. > > If I may try to express what I perceive the problem to be, we have been told that (for example, and there may be others) certain security gateways DO change the value of that FL. And presumably, for good security-minded reasons. So to say FL MUST NOT be changed is, I gather, factually not possible anymore. > > I agree that "since you can't detect whether it's been changed, mechanisms using the flow label for some purpose must be robust against unanticipated changes," however I think the hard nut is this MUST NOT be changed requirement. > > So for example, the load balancing use of FL must not cause the session to break if FL has been changed. > > Bert > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From brian.e.carpenter@gmail.com Sun May 8 19:01:12 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 B6F18E069A for ; Sun, 8 May 2011 19:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.497 X-Spam-Level: X-Spam-Status: No, score=-103.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 h-dM5rLiqOBn for ; Sun, 8 May 2011 19:01:12 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 05BF2E0684 for ; Sun, 8 May 2011 19:01:11 -0700 (PDT) Received: by iyn15 with SMTP id 15so5086248iyn.31 for ; Sun, 08 May 2011 19:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+Ks3XYDxubaJfIsGB0kI3LbJrW49Jvan2rjqgyQQmOI=; b=TMhnkz9J6zTB1ywRI2amKL0/w0VxX+T6Hw8KMHy0vo1VKHXpz4fHuymmJoAYp0Jc5p 5XS7AE5uDe4X1R6mILCVNHQyWqvGRNmbDh/l9sugLSPsYtqkdKmo1aDYfOk/EHQtOWay rd9Pckxz0hQomd7X2pg3MeVgN2+4tNjd9OXhI= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=ogWPrKfV+9e26NWqnCUdXiKqRNuuKs/PdYp7Hzm35swk0Oau879Dzi+NEjj950lRZv It3VP7Y7XxYy6StvVwYAK0ThigNLxBb+AFIuGy4cbiDfRQglFzgxyqGLW3/9HeE1ueeZ SFrhgmsM8FAL+/lNNLh/+7deO/AbI3ih2Ojlg= Received: by 10.42.157.68 with SMTP id c4mr2716298icx.208.1304906111437; Sun, 08 May 2011 18:55:11 -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 f28sm2422133ibh.33.2011.05.08.18.55.09 (version=SSLv3 cipher=OTHER); Sun, 08 May 2011 18:55:10 -0700 (PDT) Message-ID: <4DC7497B.8000208@gmail.com> Date: Mon, 09 May 2011 13:55:07 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: Flow label drafts updated References: <4DC07A80.203020 0@gmail.com><54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> <4DC721EF.70002@gmail.com> <4DC72F0F.4010107@joelhalpern.com> In-Reply-To: <4DC72F0F.4010107@joelhalpern.com> Content-Type: text/plain; charset=UTF-8 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: Mon, 09 May 2011 02:01:12 -0000 Joel, My loop detector just buzzed. This is more or less where we were a couple of drafts ago, but people said "don't say that". Now, I never delete old xml2rfc files, so I can bring back that text. However, I'd like the WG chairs to decide... Bert is correct below - if a load balancer doesn't balance the load, it won't break sessions, but it will degrade performance. Brian On 2011-05-09 12:02, Joel M. Halpern wrote: > I rather hate the following idea, and I am not sure that security > gateways would be willing to follow it. > > In order for flow label usage to actually help the ECMP hardware, we > have to expect it to work. > What if security gateways were expected to put reasonable, flow > distributing, flow -labels on their packets? > Put differently, what if security gateways were behaving as if the > received flow label were 0, and they were responsible for adding flow > labels as the spec allows? > > Yours, > Joel > > On 5/8/2011 7:21 PM, Manfredi, Albert E wrote: >> Brian E Carpenter wrote: >> >>> Nodes MUST NOT change the flow label. But since you can't detect >>> whether >>> it's been changed, mechanisms using the flow label for some purpose >>> must >>> be robust against unanticipated changes. >> >> If I may try to express what I perceive the problem to be, we have >> been told that (for example, and there may be others) certain security >> gateways DO change the value of that FL. And presumably, for good >> security-minded reasons. So to say FL MUST NOT be changed is, I >> gather, factually not possible anymore. >> >> I agree that "since you can't detect whether it's been changed, >> mechanisms using the flow label for some purpose must be robust >> against unanticipated changes," however I think the hard nut is this >> MUST NOT be changed requirement. >> >> So for example, the load balancing use of FL must not cause the >> session to break if FL has been changed. >> >> Bert >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > From jmh@joelhalpern.com Sun May 8 22:27: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 6B2AEE076E for ; Sun, 8 May 2011 22:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 XHcvfZem4p0k for ; Sun, 8 May 2011 22:27:42 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id DC3A0E06D7 for ; Sun, 8 May 2011 22:27:42 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by morbo.tigertech.net (Postfix) with ESMTP id 4C7A4CACE3 for ; Sun, 8 May 2011 18:58:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 28B893244BFD; Sun, 8 May 2011 18:58:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.10.194] (64-181-42-133.unassigned.ntelos.net [64.181.42.133]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 8ADE032447BE; Sun, 8 May 2011 18:58:45 -0700 (PDT) Message-ID: <4DC74A53.30202@joelhalpern.com> Date: Sun, 08 May 2011 21:58:43 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Flow label drafts updated References: <4DC07A80.203020 0@gmail.com><54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> <4DC721EF.70002@gmail.com> <4DC72F0F.4010107@joelhalpern.com> <4DC7497B.8000208@gmail.com> In-Reply-To: <4DC7497B.8000208@gmail.com> Content-Type: text/plain; charset=UTF-8; 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: Mon, 09 May 2011 05:27:44 -0000 As I said, I don't like what I (re-)suggested. But if we want routers to actually use this, then we need it to be sufficiently reliable. If too much stuff won't get balanced, operators will not accept the solution. Yours, Joel On 5/8/2011 9:55 PM, Brian E Carpenter wrote: > Joel, > > My loop detector just buzzed. This is more or less where we were > a couple of drafts ago, but people said "don't say that". Now, > I never delete old xml2rfc files, so I can bring back that text. > However, I'd like the WG chairs to decide... > > Bert is correct below - if a load balancer doesn't balance the load, > it won't break sessions, but it will degrade performance. > > Brian > > On 2011-05-09 12:02, Joel M. Halpern wrote: >> I rather hate the following idea, and I am not sure that security >> gateways would be willing to follow it. >> >> In order for flow label usage to actually help the ECMP hardware, we >> have to expect it to work. >> What if security gateways were expected to put reasonable, flow >> distributing, flow -labels on their packets? >> Put differently, what if security gateways were behaving as if the >> received flow label were 0, and they were responsible for adding flow >> labels as the spec allows? >> >> Yours, >> Joel >> >> On 5/8/2011 7:21 PM, Manfredi, Albert E wrote: >>> Brian E Carpenter wrote: >>> >>>> Nodes MUST NOT change the flow label. But since you can't detect >>>> whether >>>> it's been changed, mechanisms using the flow label for some purpose >>>> must >>>> be robust against unanticipated changes. >>> >>> If I may try to express what I perceive the problem to be, we have >>> been told that (for example, and there may be others) certain security >>> gateways DO change the value of that FL. And presumably, for good >>> security-minded reasons. So to say FL MUST NOT be changed is, I >>> gather, factually not possible anymore. >>> >>> I agree that "since you can't detect whether it's been changed, >>> mechanisms using the flow label for some purpose must be robust >>> against unanticipated changes," however I think the hard nut is this >>> MUST NOT be changed requirement. >>> >>> So for example, the load balancing use of FL must not cause the >>> session to break if FL has been changed. >>> >>> Bert >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> > From v6ops@globis.net Mon May 9 04:42: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 67AAEE06D3 for ; Mon, 9 May 2011 04:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] 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 tsKQHGzay8yc for ; Mon, 9 May 2011 04:42:48 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2C482E068D for ; Mon, 9 May 2011 04:42:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 44C188700E6; Mon, 9 May 2011 13:36:52 +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 SjjiydrO-X1B; Mon, 9 May 2011 13:36:46 +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 323158700DD; Mon, 9 May 2011 13:36:46 +0200 (CEST) Message-ID: <4DC7D1C0.7050708@globis.net> Date: Mon, 09 May 2011 13:36:32 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Arifumi Matsumoto Subject: Re: draft-ietf-6man-rfc3484-revise@tools.ietf.org References: <4DBE8E35.7080008@globis.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060804080009050900060308" Cc: ipv6@ietf.org, fujisaki@syce.net 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, 09 May 2011 11:42:50 -0000 This is a multi-part message in MIME format. --------------060804080009050900060308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thank you very much for replying to my message. I have copied the 6man mailing list into the reply, plus your original mail is attached below, as you requested, so as to involve a larger community in the discussion. Yes. You have a humble opinion that ISATAP is equivalent to native IPv6 and therefore RFC 3484 bis is already adequate to cover all use cases. And I have a different humble opinion, that I like native IPv6, but I think ISATAP is worse than native IPv4, and this use-case cannot be coded into RFC3484 bis. Both of us may be correct, dependent of the deployment scenario. My customers generally have excellent native IPv4 networks. I'm sure that they want to build excellent native IPv6 networks. ANY tunnel is likely to be worse than their support of either native protocol. And an automatic tunnel where the end points may physically move (think traveling users) even more so. The point is that my humble opinion cannot be encoded into RFC3484 bis as proposed. Indeed I cannot configure any implementation of ISATAP that I know of today to behave as I desire. I have no way of controlling the relative preference of native IPv6, versus IPv6 over ISATAP over IPv4, versus native IPv4. I can either prefer all IPv6 above all IPv4, or all IPv4 above all IPv6. But I can't get any more granular than that. That to my mind is not enough, because we do not know the exact deployment decisions that are going to be made by all network managers in the move to IPv6. The 6man WG can assume that ISATAP is equivalent to native IPv6, but some others may conclude otherwise. I have posted elsewhere about my opinions on the lack of adequate control in ISATAP in the v6ops WG in reply to the draft http://tools.ietf.org/html/draft-templin-v6ops-isops-00 To summarise: Because ISATAP is a host to gateway tunnel, it has no in-built way of controlling/ limiting additional network latency, nor of correctly applying DSCP QoS settings, nor can it be filtered by today's firewalls in a granular manner. So ISATAP is certainly not equivalent to native IPv6 in my mind. It also relies heavily on management of one particular DNS / WINS name space content (which may be dynamically updated as part of standard Windows AD operation), which IMHO is no way to control a network. One inquisitive/ incompetent server admin setting his Windows server name to "isatap" can change the behavior of 10000+ nodes on an international corporate network. That's not my definition of "managed." So my conclusion is that I have to switch ISATAP off, everywhere, until those shortcomings are addressed. I'm not asking the 6man WG to "fix" the shortcomings of ISATAP, although that would be nice. All I'm asking you guys to consider is whether your RFC3484 bis draft is complete if it cannot encode ALL combinations of preferences regarding which native network protocol or transition mechanism to prefer over another. The IETF does not control or mandate all deployment scenarios. Nor should it. In particular I ask you to further examine supporting the use case: native IPv6 >> native IPv4 >> IPv6 over ISATAP over IPv4. BTW just to say something very positive: the extension of RFC3484 bis to include ISATAP prioritization + DHCP(v6) distribution would likely be an extremely useful mechanism for controlling default end node behaviour in multinational companies (where AD may not be universally deployed). So keep up the good work in http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-00 best regards, RayH Arifumi Matsumoto wrote: > Ray, > > On 2011/05/02, at 19:57, Ray Hunter wrote: > > >> Appreciate your work on RFC3484 bis. I sent a comment regarding http://www.ietf.org/id/draft-ietf-6man-rfc3484-revise-02.txt via the IETF web site, but I have a suspicion it black-holed. >> >> Excuse me if I'm barking up the wrong tree here. Also forgive me if I'm wrong because interpreting some of these rules confuse me a lot. >> > > These addresses are good. But, the ietf mailing list 6man may be even more better in that you can gather comments from more people. > > >> ISATAP (RFC5214) uses an IPv6 node identifier (based on an IPv4 address) that is appended to a standard IPv6 /64 prefix to create an IPv6 overlay network over an existing IPv4 network. So far so good, it provides IPv6 connectivity over IPv4 to IPv6 only hosts. >> >> But what about dual stack hosts? >> >> Given that you have now concluded that 6to4 is bad, and Teredo is even worse, because it is based on a transition mechanism that works over a dynamic tunnel, shouldn't IPv6 over ISATAP be similarly assigned a low priority compared to native IPv4? >> > > I do not think all the transition mechanisms should be less-preferred. > 6to4 and Teredo are un-managed transition mechanisms, so they are less-preferred for that reason. > IMO, ISATAP is deployed and controlled by a site administrator who may be ISP or enterprise network admin. > So, I do not think it is unmanaged. > > >> In Microsoft's book "Understanding IPv6 v2" on page 219-221, they even give an example showing how ISATAP combined with a global unique IPv6 unicast prefix would be preferred over native IPv4. >> >> I can't imagine a single case of a dual stack host that would get better performance using IPv6 over ISATAP over IPv4 than it would get over a native IPv4 connection. Unless we are in the last days of IPv4, and there really are only IPv4 islands left. >> > > Just like 6rd, IPv6 may not be better than IPv4 with regard to MTU. > However that point alone should not be a reasonable motivation to de-prioritize IPv6. > > >> Then again, I'm not at all sure how you could handle that in a RFC3484 bis type policy table, given that ISATAP does not conform to the comfortable notion that all mechanisms are left-anchored in the addressing scheme / are IPv6 prefix length based. >> >> Maybe the whole mechanism needs a review? >> >> Or ISATAP needs moving to historic status? >> > > RFC3484-bis does not include any changes with regard to ISATAP. > And, as I mentioned above, IMO ISATAP should be just treated like global IPv6 addresses. > > Best regards, > > -- > Arifumi Matsumoto > NGN System Architecture Project > NTT Service Integration Laboratories > E-mail: arifumi@nttv6.net > TEL +81-422-59-3334 FAX +81-422-59-6364 > > --------------060804080009050900060308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thank you very much for replying to my message.

I have copied the 6man mailing list into the reply, plus your original mail is attached below, as you requested, so as to involve a larger community in the discussion.

Yes. You have a humble opinion that ISATAP is equivalent to native IPv6 and therefore RFC 3484 bis is already adequate to cover all use cases.

And I have a different humble opinion, that I like native IPv6, but I think ISATAP is worse than native IPv4, and this use-case cannot be coded into RFC3484 bis.

Both of us may be correct, dependent of the deployment scenario. My customers generally have excellent native IPv4 networks. I'm sure that they want to build excellent native IPv6 networks. ANY tunnel is likely to be worse than their support of either native protocol. And an automatic tunnel where the end points may physically move (think traveling users) even more so.

The point is that my humble opinion cannot be encoded into RFC3484 bis as proposed. Indeed I cannot configure any implementation of ISATAP that I know of today to behave as I desire. I have no way of controlling the relative preference of native IPv6, versus IPv6 over ISATAP over IPv4, versus native IPv4.

I can either prefer all IPv6 above all IPv4, or all IPv4 above all IPv6. But I can't get any more granular than that. That to my mind is not enough, because we do not know the exact deployment decisions that are going to be made by all network managers in the move to IPv6. The 6man WG can assume that ISATAP is equivalent to native IPv6, but some others may conclude otherwise.

I have posted elsewhere about my opinions on the lack of adequate control in ISATAP in the v6ops WG in reply to the draft http://tools.ietf.org/html/draft-templin-v6ops-isops-00

To summarise: Because ISATAP is a host to gateway tunnel, it has no in-built way of controlling/ limiting additional network latency, nor of correctly applying DSCP QoS settings, nor can it be filtered by today's firewalls in a granular manner. So ISATAP is certainly not equivalent to native IPv6 in my mind. It also relies heavily on management of one particular DNS / WINS name space content (which may be dynamically updated as part of standard Windows AD operation), which IMHO is no way to control a network. One inquisitive/ incompetent server admin setting his Windows server name to "isatap" can change the behavior of 10000+ nodes on an international corporate network. That's not my definition of "managed." So my conclusion is that I have to switch ISATAP off, everywhere, until those shortcomings are addressed.

I'm not asking the 6man WG to "fix" the shortcomings of ISATAP, although that would be nice.

All I'm asking you guys to consider is whether your RFC3484 bis draft is complete if it cannot encode ALL combinations of preferences regarding which native network protocol or transition mechanism to prefer over another. The IETF does not control or mandate all deployment scenarios. Nor should it.

In particular I ask you to further examine supporting the use case: native IPv6 >> native IPv4 >> IPv6 over ISATAP over IPv4.

BTW just to say something very positive: the extension of RFC3484 bis to include ISATAP prioritization + DHCP(v6) distribution would likely be an extremely useful mechanism for controlling default end node behaviour in multinational companies (where AD may not be universally deployed). So keep up the good work in http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-00

best regards,
RayH

Arifumi Matsumoto wrote: 
Ray,

On 2011/05/02, at 19:57, Ray Hunter wrote:

  
Appreciate your work on RFC3484 bis. I sent a comment regarding http://www.ietf.org/id/draft-ietf-6man-rfc3484-revise-02.txt via the IETF web site, but I have a suspicion it black-holed.

Excuse me if I'm barking up the wrong tree here. Also forgive me if I'm wrong because interpreting some of these rules confuse me a lot.
    

These addresses are good. But, the ietf mailing list 6man may be even more better in that you can gather comments from more people.

  
ISATAP (RFC5214) uses an IPv6 node identifier (based on an IPv4 address) that is appended to a standard IPv6 /64 prefix to create an IPv6 overlay network over an existing IPv4 network. So far so good, it provides IPv6 connectivity over IPv4 to IPv6 only hosts.

But what about dual stack hosts?

Given that you have now concluded that 6to4 is bad, and Teredo is even worse, because it is based on a transition mechanism that works over a dynamic tunnel, shouldn't IPv6 over ISATAP be similarly assigned a low priority compared to native IPv4?
    

I do not think all the transition mechanisms should be less-preferred.
6to4 and Teredo are un-managed transition mechanisms, so they are less-preferred for that reason.
IMO, ISATAP is deployed and controlled by a site administrator who may be ISP or enterprise network admin.
So, I do not think it is unmanaged.

  
In Microsoft's book "Understanding IPv6 v2" on page 219-221, they even give an example showing how ISATAP combined with a global unique IPv6 unicast prefix would be preferred over native IPv4.

I can't imagine a single case of a dual stack host that would get better performance using IPv6 over ISATAP over IPv4 than it would get over a native IPv4 connection. Unless we are in the last days of IPv4, and there really are only IPv4 islands left.
    

Just like 6rd, IPv6 may not be better than IPv4 with regard to MTU.
However that point alone should not be a reasonable motivation to de-prioritize IPv6.

  
Then again, I'm not at all sure how you could handle that in a RFC3484 bis type policy table, given that ISATAP does not conform to the comfortable notion that all mechanisms are left-anchored in the addressing scheme / are IPv6 prefix length based.

Maybe the whole mechanism needs a review?

Or ISATAP needs moving to historic status?
    

RFC3484-bis does not include any changes with regard to ISATAP.
And, as I mentioned above, IMO ISATAP should be just treated like global IPv6 addresses.

Best regards,

--
Arifumi Matsumoto
  NGN System Architecture Project
  NTT Service Integration Laboratories
  E-mail: arifumi@nttv6.net
  TEL +81-422-59-3334 FAX +81-422-59-6364

--------------060804080009050900060308-- From rja.lists@gmail.com Mon May 9 06:02: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 08D28E067E for ; Mon, 9 May 2011 06:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 UdNsj7RjHL0H for ; Mon, 9 May 2011 06:02:32 -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 2EC33E065D for ; Mon, 9 May 2011 06:02:31 -0700 (PDT) Received: by qyk7 with SMTP id 7so3909560qyk.10 for ; Mon, 09 May 2011 06:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=Q21/XQr/nRpexV2zzNkRTAEOTF+if7WhVoCAmEWn78Y=; b=K/H2EbDsrMxMda37dBOOP1mvU/00Vj5zjH3FF3f3qZSe6mNJNblr8z8o8VBMVqtjDf FDpFMPOn6yF2J2/DdcRxAKfJSsJWuJRTVLMCvsx08REHB1oaXewOOHz9aNbEulQbZ98N uMEAf0NCSVxeCecA3BDIrD38prl8MH27VmkQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=hiEde65r36XrWH2dn5ceoJ3vdNwGdIxmYmdkZxf5l0e3CY25vPprkwa4wv6VCMld41 UbDgqDPxGG3OLapIIQH6vt84egWy5aVFnIw6T1OKbw6pbhQgrURRvLLDIEhVYLob4eEY bmTyuesbbTuE7U+ysPxZIJn4qaN+TWBedOND8= Received: by 10.229.191.207 with SMTP id dn15mr1356393qcb.183.1304946151082; Mon, 09 May 2011 06:02:31 -0700 (PDT) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id s16sm5129409qco.1.2011.05.09.06.02.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 06:02:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: Flow label drafts updated From: RJ Atkinson In-Reply-To: <4DC721EF.70002@gmail.com> Date: Mon, 9 May 2011 09:02:28 -0400 Content-Transfer-Encoding: 7bit Message-Id: <9DAEFCBC-9814-49BA-AA0A-ED478CF0E8A9@gmail.com> References: <4DC07A80.2030200@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> <4DC721EF.70002@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1084) 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, 09 May 2011 13:02:36 -0000 On 08 May 2011, at 19:06 , Brian E Carpenter wrote: > Maybe it's just the use of the word "immutable" that is causing the > problem here, because it implies something that physically isn't true. I think that is a very very important part, possibly the central element, of this discussion. This is a large part of why Wes's concerns, Fernando's concerns, and my concerns are in fact deeply intertwined with Thomas Narten's concerns. IMHO, trying to prohibit change in the Flow Label is about as sensible as the USA's attempt last century to prohibit all consumption of alcohol. (For folks outside the USA, that attempt failed miserably and within N years "prohibition" was repealed.) A much more reasonable approach would be to say (edit to taste): "The Flow Label SHOULD NOT be changed in transit." probably coupled with (also, edit to taste): "If the Flow Label is changed in transit (e.g. due to operational security considerations), then the Flow Label should be changed to a value that complies with the mathematical requirements for use in load balancing." A security gateway is by definition trusted. So it could take a non-zero value that potential contains hidden information and replace it with some different non-zero value that the gateway knows does not contain hidden information. So long as both values comply with the mathematical requirements for load-balancing, there is no adverse impact on the operational goals of the current drafts. It would be reasonable to prohibit taking a non-zero value and making it zero, IMHO. Although deployed systems are not likely to change their behaviour, over time such systems might get upgraded to rewrite in a way that both meets security requirements and also meets the load-balancing objectives. Yours, Ran From rja.lists@gmail.com Mon May 9 06:10:28 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 82E25E06F5 for ; Mon, 9 May 2011 06:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.242 X-Spam-Level: X-Spam-Status: No, score=-3.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 NiGidGoaGn4X for ; Mon, 9 May 2011 06:10:27 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE1CE069F for ; Mon, 9 May 2011 06:10:26 -0700 (PDT) Received: by qyk29 with SMTP id 29so945359qyk.10 for ; Mon, 09 May 2011 06:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=3yRHi0LENckS7vWbYxslU4rVVuCzERreukPpecZdhX0=; b=qIyM+iaWw+HKkehVGJoHdxjxLMHuFM+ovVy5kwA7YdJIxWxA5IyqzX2s9X8LZOdu4+ L5D+D9m1GJYP6BOIryJ9ow58ohMClc3NqO9pp/9/fdnCwQVmRmG2hLGwd+nRO2N2hmTy 0DnIu++t+yg1u4OJ24sThEonwy44l4QDouyZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=s7sJstYfeFBrWgpF4s2NrTerq2RvhY4343dCxW/ve9PKXYWxGOujNNB8TIv4kptDwm IXfw5gHuWBG0D8ofhCJo7yAz/oGzscW+Yte+PtVwXXA2siiaa5gxOoHsbdEeOpuqqGXR mbiUH9sbqtEz6tnBMu8avGxV0+RV1oc4mJ39c= Received: by 10.224.212.2 with SMTP id gq2mr286780qab.88.1304946625726; Mon, 09 May 2011 06:10:25 -0700 (PDT) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id m9sm59599qcu.15.2011.05.09.06.10.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 06:10:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: Flow label drafts updated From: RJ Atkinson In-Reply-To: <4DC72BAD.7020007@gmail.com> Date: Mon, 9 May 2011 09:10:23 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4DC07A80.2030200@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> <201105061326.p46DQksH014118@cichlid.raleigh.ibm.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C90694@PDAWM12B.ad.sprint.com> <4DC49F04.40900@gmail.com> <4DC72BAD.7020007@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1084) 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, 09 May 2011 13:10:28 -0000 On 08 May 2011, at 19:47 , Brian E Carpenter wrote: > But it's really playing with words to assert that a firewall which > chooses to overwrite the field is "supporting" it in the sense > intended by the phrase "Hosts or routers that do not support the > functions of the Flow Label field...". It is not playing with words. Those security gateways normally are also routers, using the formal IPv6 definition of a router, often participate in routing protocols (e.g. eBGP in the case of multi-homed uplinks from an end-site; OSPF or RIP within an end -site) as routers, and often use the Flow Label value as input to their forwarding decisions. > The technical issue is that load balancing based on flow label values > won't work properly if middleboxes (or attackers) change the values > arbitrarily. As near as I can tell, everyone here agrees on the objective of enabling the Flow Label to be useful for load-balancing. As my note of a few moments ago suggested, there is a way to address both the operational security concerns and the load-balancing objectives. Rather than repeat myself, I'll just refer back to that note. > Thomas has argued that if the label MUST NOT be changed, we should > remove any suggestion of cases in which it's OK to change it. Followed > to its logical conclusion, that means it's not OK for a firewall to > change it. The crux of his concern seems to be that the current text tries to have things both ways, which ambiguity is long-standing, as I noted in my weekend email. I hope, perhaps overly optimistically, that the formula I proposed in my note of a few moments ago will find middle ground that most folks find acceptable. Cheers, Ran From jinmei@isc.org Mon May 9 12:58:11 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 41DA6E0856 for ; Mon, 9 May 2011 12:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.2 X-Spam-Level: * X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_46=0.6, NO_RELAYS=-0.001] 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 Aot2uKCP7LA9 for ; Mon, 9 May 2011 12:58:10 -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 95632E08AE for ; Mon, 9 May 2011 12:58:10 -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 8FD9C5F992D; Mon, 9 May 2011 19:58:04 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (unknown [IPv6:2001:4f8:3:64:c62c:3ff:fe1f:6c75]) (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 7C088216C40; Mon, 9 May 2011 19:58:02 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Mon, 09 May 2011 12:58:01 -0700 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten Subject: Re: Short 6MAN WG Last Call: In-Reply-To: <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Bob Hinden , 6man Mailing List , Brian Haberman 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, 09 May 2011 19:58:11 -0000 At Fri, 06 May 2011 13:48:19 -0400, Thomas Narten wrote: > I'm not entirely sure what to do here. RFC 4191 is not widely > implemented, AFAIK. It's in Windows Vista (and onwards) and also > Linux. Not sure where else (I'm guessing not on Macs?) (I'm not sure if the following information is really relevant to the discussion context, but am providing some fact in case it does.) Many major BSD variants (including FreeBSD) have been supporting the host part of default router preferences (but not more specific routes) for quite a long time (according to the source code repository, this feature was incorporated to FreeBSD in October 2005). I don't know the details of MacOS X on this point (or I'm so lazy that I've not checked its behavior using my laptop), but it at least seems to recognize the preference value: % ndp -r fe80::230:48ff:feb9:9a5c%en0 if=en0, flags=, pref=medium, expire=23m7s (note the "pref" field) --- JINMEI, Tatuya Internet Systems Consortium, Inc. From brian.e.carpenter@gmail.com Mon May 9 16:00: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 7AB14E068B for ; Mon, 9 May 2011 16:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.508 X-Spam-Level: X-Spam-Status: No, score=-103.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 X4o5iqXqYlVS for ; Mon, 9 May 2011 16:00:35 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52C9BE067B for ; Mon, 9 May 2011 16:00:35 -0700 (PDT) Received: by pwi5 with SMTP id 5so3465508pwi.31 for ; Mon, 09 May 2011 16:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EHuppBLAeeo2msKlflVI7bfk7B8Ukxfe2eCHp64KPcI=; b=Yl+Mq3jZt1vkJoZIKQ/ANsEEXO3E3zxyJ/ykzh7ohAxYM4V4NS1cJd5HY48qDts/hd FeDqIrZGKEJ3KpK8IxOPz2KpgnrYXmlDAGZ5uuIHKFzhLkim/K5LI+0y4aNgj/IAEWp/ 7ek7+uB49yfe4gwzOdsuJ/tl3nOHQFx7a0PD8= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Xi9Zrqg7WW3FOrJWLQzIdLODKcLNuMVlbiw4IrXCN4BWOFHyNYQy/4/prhrsKmiB9d 1LYdAQxJG2M6fBwRh8RScshFfJw41DkKckLjv43i60F6C/rWlYAkGkA+IqomeOl5K9GK Xqy//5MTAiUTIPxGAl1ontOMTZtQ3SP0O2DAc= Received: by 10.68.13.7 with SMTP id d7mr9994631pbc.311.1304982034320; Mon, 09 May 2011 16:00:34 -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 r5sm4390324pbe.101.2011.05.09.16.00.32 (version=SSLv3 cipher=OTHER); Mon, 09 May 2011 16:00:33 -0700 (PDT) Message-ID: <4DC8720E.3030601@gmail.com> Date: Tue, 10 May 2011 11:00:30 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: Flow label drafts updated References: <4DC07A80.2030200@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> <4DC721EF.70002@gmail.com> <9DAEFCBC-9814-49BA-AA0A-ED478CF0E8A9@gmail.com> In-Reply-To: <9DAEFCBC-9814-49BA-AA0A-ED478CF0E8A9@gmail.com> Content-Type: text/plain; charset=UTF-8 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: Mon, 09 May 2011 23:00:36 -0000 Hi Ran, On 2011-05-10 01:02, RJ Atkinson wrote: > On 08 May 2011, at 19:06 , Brian E Carpenter wrote: >> Maybe it's just the use of the word "immutable" that is causing the >> problem here, because it implies something that physically isn't true. > > I think that is a very very important part, possibly the > central element, of this discussion. This is a large part > of why Wes's concerns, Fernando's concerns, and my concerns > are in fact deeply intertwined with Thomas Narten's concerns. > > IMHO, trying to prohibit change in the Flow Label is about > as sensible as the USA's attempt last century to prohibit all > consumption of alcohol. (For folks outside the USA, that attempt > failed miserably and within N years "prohibition" was repealed.) > > A much more reasonable approach would be to say (edit to taste): > > "The Flow Label SHOULD NOT be changed in transit." The authors really need to hear that from more than one person, or to hear from the WG Chairs that it's a consensus, because it goes against several months of discussion. > > probably coupled with (also, edit to taste): > > "If the Flow Label is changed in transit (e.g. due to > operational security considerations), then the Flow Label > should be changed to a value that complies with the > mathematical requirements for use in load balancing." Well, others have said 'don't say that', in response to earlier versions with loosely equivalent text, so again the authors need to be told what the consensus is. As Ray Hunter said on another thread, reality suggests that the IETF should recognise the existence of firewalls... so why not be explicit? I suggest squaring this circle by retaining the MUST NOT (which IMHO is the present consensus) but making it clear in the security considerations that there will be exceptions. The problem here is that the RFC 2119 language doesn't provide MUST NOT UNLESS..., which is what we really need. SHOULD NOT is not perceived as strong enough. > > A security gateway is by definition trusted. So it could take > a non-zero value that potential contains hidden information and > replace it with some different non-zero value that the gateway > knows does not contain hidden information. So long as both > values comply with the mathematical requirements for load-balancing, > there is no adverse impact on the operational goals of the current > drafts. It would be reasonable to prohibit taking a non-zero value > and making it zero, IMHO. Agreed. Brian > Although deployed systems are not likely > to change their behaviour, over time such systems might get upgraded > to rewrite in a way that both meets security requirements and also > meets the load-balancing objectives. > > Yours, > > Ran > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From brian.e.carpenter@gmail.com Mon May 9 16:10:07 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 73EDFE0744 for ; Mon, 9 May 2011 16:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.51 X-Spam-Level: X-Spam-Status: No, score=-103.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 C5Slo+hHWPd9 for ; Mon, 9 May 2011 16:10:06 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 93C20E072C for ; Mon, 9 May 2011 16:10:05 -0700 (PDT) Received: by pwi5 with SMTP id 5so3469175pwi.31 for ; Mon, 09 May 2011 16:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=B4t5grTiIyGZjgrS5zg+bBU6ZvfCrOClZ0kaOBwlNuU=; b=EZxpZpN5n1E49vm0xvkgH93tx8UPO04g8mLTgDOq4ZZQiVEJYKrbSQfyFazJJi/o+V 2gPzYYLXe+NVt54tdLUYv1UWRd6Dh0eJakJNC4AtHWXbtjYBIOVps+ccrYLcJrI5XEk8 iSEwlYnt5iXnyyAel3ASMN1FVBXSD7eFOiFfw= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=bmhcmUxJuWYgPRagpcNBTHI2C6uAaEc7O63cufapWLNatPr870oyE12IgGQPb71edD DheGkQaMPrcQ+FQh26Z/xRiz0AwJxQSUzJsa+jic/o40iigL1kT9L8acrlQzH22vBGc9 lLsSfx2EXoVV0zx/7rrEgUETqrp3yDLM7r3hc= Received: by 10.68.30.194 with SMTP id u2mr8049435pbh.295.1304982250564; Mon, 09 May 2011 16:04:10 -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 d9sm4390923pba.16.2011.05.09.16.04.08 (version=SSLv3 cipher=OTHER); Mon, 09 May 2011 16:04:09 -0700 (PDT) Message-ID: <4DC872E6.3080504@gmail.com> Date: Tue, 10 May 2011 11:04:06 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: Flow label drafts updated References: <4DC07A80.2030200@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> <201105061326.p46DQksH014118@cichlid.raleigh.ibm.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C90694@PDAWM12B.ad.sprint.com> <4DC49F04.40900@gmail.com> <4DC72BAD.7020007@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: Mon, 09 May 2011 23:10:07 -0000 Hi again Ran, On 2011-05-10 01:10, RJ Atkinson wrote: > On 08 May 2011, at 19:47 , Brian E Carpenter wrote: >> But it's really playing with words to assert that a firewall which >> chooses to overwrite the field is "supporting" it in the sense >> intended by the phrase "Hosts or routers that do not support the >> functions of the Flow Label field...". > > It is not playing with words. Those security gateways normally > are also routers, using the formal IPv6 definition of a router, > often participate in routing protocols (e.g. eBGP in the case > of multi-homed uplinks from an end-site; OSPF or RIP within an > end -site) as routers, and often use the Flow Label value as input > to their forwarding decisions. Really? There are routers today that look at the flow label? > >> The technical issue is that load balancing based on flow label values >> won't work properly if middleboxes (or attackers) change the values >> arbitrarily. > > As near as I can tell, everyone here agrees on the objective of > enabling the Flow Label to be useful for load-balancing. > > As my note of a few moments ago suggested, there is a way to address > both the operational security concerns and the load-balancing objectives. > Rather than repeat myself, I'll just refer back to that note. Ack > > >> Thomas has argued that if the label MUST NOT be changed, we should >> remove any suggestion of cases in which it's OK to change it. Followed >> to its logical conclusion, that means it's not OK for a firewall to >> change it. > > The crux of his concern seems to be that the current text tries > to have things both ways, which ambiguity is long-standing, > as I noted in my weekend email. > > I hope, perhaps overly optimistically, that the formula I proposed > in my note of a few moments ago will find middle ground that most > folks find acceptable. As I just commented, we seem to be squaring the circle and the authors need to be told what the WG consensus is... Brian From john@jlc.net Mon May 9 16:54:49 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 CBBE2E0806 for ; Mon, 9 May 2011 16:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.424 X-Spam-Level: X-Spam-Status: No, score=-106.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 uuT0o7oRtx3K for ; Mon, 9 May 2011 16:54:49 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 38875E07E4 for ; Mon, 9 May 2011 16:54:48 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5039133C23; Mon, 9 May 2011 19:27:07 -0400 (EDT) Date: Mon, 9 May 2011 19:27:07 -0400 From: John Leslie To: Brian E Carpenter Subject: Re: Flow label drafts updated Message-ID: <20110509232707.GL49185@verdi> References: <4DC07A80.2030200@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> <4DC721EF.70002@gmail.com> <9DAEFCBC-9814-49BA-AA0A-ED478CF0E8A9@gmail.com> <4DC8720E.3030601@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DC8720E.3030601@gmail.com> User-Agent: Mutt/1.4.1i Cc: ipv6@ietf.org, RJ Atkinson 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, 09 May 2011 23:54:49 -0000 Brian E Carpenter wrote: > On 2011-05-10 01:02, RJ Atkinson wrote: > >> A much more reasonable approach would be to say (edit to taste): >> >> "The Flow Label SHOULD NOT be changed in transit." > > The authors really need to hear that from more than one person, or to > hear from the WG Chairs that it's a consensus, because it goes against > several months of discussion. I agree with Ran that SHOULD NOT is more appropriate for this case where the horse has long since left the barn. Middleboxes _are_ going to clear it (or worse). OTOH, I don't actually _object_ to MUST NOT -- in the narrow sense that any node that disobeys the MUST NOT isn't speaking the protocol as defined. I do believe we should, regardless, excise all use of the word "immutable" for the Flow Label. That word isn't helping. > I suggest squaring this circle by retaining the MUST NOT (which IMHO > is the present consensus) but making it clear in the security > considerations that there will be exceptions. The problem here is that > the RFC 2119 language doesn't provide MUST NOT UNLESS..., which is > what we really need. SHOULD NOT is not perceived as strong enough. I could live with that; but I really do suggest wordsmithing the 3 uses of "immutable". Additionally, I'd like to see some treatment of what may go wrong if middleboxes change the Flow Label. If I understand, it will partly break load-balancing. Middlebox designers probably don't understand this issue. (Even if they did, they'd likely say, "some users are entirely willing to accept that tradeoff.") -- John Leslie From bob.hinden@gmail.com Mon May 9 16:58: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 26649E0836 for ; Mon, 9 May 2011 16:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.24 X-Spam-Level: X-Spam-Status: No, score=-103.24 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 GpXZL8Syn6oz for ; Mon, 9 May 2011 16:58:56 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE19E081B for ; Mon, 9 May 2011 16:58:56 -0700 (PDT) Received: by pvh1 with SMTP id 1so3481763pvh.31 for ; Mon, 09 May 2011 16:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=SmQ+H6bxqXCrqVp09dYRsiIquVe81VzBDRIdBDDJAEw=; b=OTt/cNvN86oAWIr/sQTR6WIJqe+JYJDgcWI8gbrCSHo3EVVXTv7tDiE0f2KB5YrV7N +ShFWA0ty75CEqHYTUbHuCBhCi5DqHqVEoYK0z24342aDD4+xafWKjqxENvAbjy+Abuj Y03E3kf6LsKd4D53Vx8ELKdjyLb1CJwhG365s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=uUdqNQcNIU52LxXnLGGLJCCj7lp1m671o1aYZmCHDwMrZVZn3L6jsssTK5eOhlHPbg Xc/FxW83t9IjkhEsIJVU9472eLuMdFgnD7Nr3nEHskX0yhBuCh1PLcsuM7nUzaHm3rQd RUrA1OrOFhYzxHdfb3Ry1OLoMOp2VQx+BkfFI= Received: by 10.68.41.103 with SMTP id e7mr1770824pbl.43.1304985535774; Mon, 09 May 2011 16:58:55 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id l9sm3390416pbc.14.2011.05.09.16.58.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 16:58:54 -0700 (PDT) Subject: Re: Short 6MAN WG Last Call: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Bob Hinden In-Reply-To: Date: Mon, 9 May 2011 16:58:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1C30F071-AD2E-4D55-9AAD-FCE7629BBC06@gmail.com> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: 6man Mailing List , Bob Hinden , Brian Haberman 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, 09 May 2011 23:58:57 -0000 Thomas, My personal observation, if it's implemented in Windows Vista & WIn7, = Linux, BSD, (and probably Macs), then this sounds like widely = implemented. This plus Ole's use scenario, leads me to think it should = be a SHOULD. =20 Bob On May 9, 2011, at 12:58 PM, JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5= =93=89 wrote: > At Fri, 06 May 2011 13:48:19 -0400, > Thomas Narten wrote: >=20 >> I'm not entirely sure what to do here. RFC 4191 is not widely >> implemented, AFAIK. It's in Windows Vista (and onwards) and also >> Linux. Not sure where else (I'm guessing not on Macs?) >=20 > (I'm not sure if the following information is really relevant to the > discussion context, but am providing some fact in case it does.) >=20 > Many major BSD variants (including FreeBSD) have been supporting the > host part of default router preferences (but not more specific routes) > for quite a long time (according to the source code repository, this > feature was incorporated to FreeBSD in October 2005). I don't know > the details of MacOS X on this point (or I'm so lazy that I've not > checked its behavior using my laptop), but it at least seems to > recognize the preference value: >=20 > % ndp -r > fe80::230:48ff:feb9:9a5c%en0 if=3Den0, flags=3D, pref=3Dmedium, = expire=3D23m7s > (note the "pref" field) >=20 > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. From narten@us.ibm.com Mon May 9 17:16:14 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 3BA83E0778 for ; Mon, 9 May 2011 17:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.335 X-Spam-Level: X-Spam-Status: No, score=-105.335 tagged_above=-999 required=5 tests=[AWL=1.264, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 gtVbb212gbpR for ; Mon, 9 May 2011 17:16:13 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id A8A4FE0715 for ; Mon, 9 May 2011 17:16:13 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e31.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p49Nxrkg031620 for ; Mon, 9 May 2011 17:59:53 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4A0G2ts150936 for ; Mon, 9 May 2011 18:16:02 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p49IG1dm017731 for ; Mon, 9 May 2011 12:16:02 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-76-148-57.mts.ibm.com [9.76.148.57]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p49IG0nx017664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 12:16:01 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4A0FwW3016108; Mon, 9 May 2011 20:15:58 -0400 Message-Id: <201105100015.p4A0FwW3016108@cichlid.raleigh.ibm.com> To: Bob Hinden Subject: Re: Short 6MAN WG Last Call: In-reply-to: <1C30F071-AD2E-4D55-9AAD-FCE7629BBC06@gmail.com> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <1C30F071-AD2E-4D55-9AAD-FCE7629BBC06@gmail.com> Comments: In-reply-to Bob Hinden message dated "Mon, 09 May 2011 16:58:52 -0700." Date: Mon, 09 May 2011 20:15:58 -0400 From: Thomas Narten Cc: 6man Mailing List , Brian Haberman 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, 10 May 2011 00:16:14 -0000 > My personal observation, if it's implemented in Windows Vista & > WIn7, Linux, BSD, (and probably Macs), then this sounds like widely > implemented. This plus Ole's use scenario, leads me to think it > should be a SHOULD. I could probably go with a SHOULD. But, I wonder if we are living in the past using the above as representative of implementations. When are we going to start counting cell phones, tablets and other electronic devices? I've seen various stats that say traditional PCs will be a minority of devices accessing the Internet sometime this year. (Of course, the overall percentage of such devices with IPv6 makes the argument sort of moot, but that's a detail...) Thomas From bob.hinden@gmail.com Mon May 9 17:24:10 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 06E89E0867 for ; Mon, 9 May 2011 17:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.527 X-Spam-Level: X-Spam-Status: No, score=-103.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 vlpyBtUNDu+l for ; Mon, 9 May 2011 17:24:09 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0D1E0865 for ; Mon, 9 May 2011 17:24:09 -0700 (PDT) Received: by pxi2 with SMTP id 2so3545623pxi.38 for ; Mon, 09 May 2011 17:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=12AqiFI1/+WJNUj5/TuFkWfTR+eBul+rVAnb5swEvAU=; b=enmxi/Cwt5+/+neeN4tevRn7ZIlPfbi9YYwQUik/gu8qIgTbnEK62P0/bOZ3IbXcsC HIOAL9gFcXYLEFsCn2+m2L9MWT3OYkQiWEcwRxc18M5UHGbuzrORAQtywOiPp7/YjzOt 8aLdMukCGpaHVAgZ7XPYhsCUuvaVdcwiP17lI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=D4sXRNvjAxxoLlJZMQxPn6zg0sLG1raT/0QLHM6qT1sJ6U3ANqh1otpjzCYpFAVGe8 1uR+49TTDBEzWyZuyJQn93gRfjCi6bizA5yaCthf08krlGf8S3WdkCGiZqMEl2OS8lP9 bFQRXWEIOcVZ8EbyrXqEGD58OVG9z3CTB2eEc= Received: by 10.68.66.101 with SMTP id e5mr385077pbt.447.1304987048401; Mon, 09 May 2011 17:24:08 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id c4sm427576pbn.37.2011.05.09.17.24.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 17:24:07 -0700 (PDT) Subject: Re: Short 6MAN WG Last Call: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <201105100015.p4A0FwW3016108@cichlid.raleigh.ibm.com> Date: Mon, 9 May 2011 17:24:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4E9ECC9C-1648-4270-8736-C6ADD7379EA0@gmail.com> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <1C30F071-AD2E-4D55-9AAD-FCE7629BBC06@gmail.com> <201105100015.p4A0FwW3016108@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: 6man Mailing List , Bob Hinden , Brian Haberman 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, 10 May 2011 00:24:10 -0000 Thomas, On May 9, 2011, at 5:15 PM, Thomas Narten wrote: >> My personal observation, if it's implemented in Windows Vista & >> WIn7, Linux, BSD, (and probably Macs), then this sounds like widely >> implemented. This plus Ole's use scenario, leads me to think it >> should be a SHOULD. >=20 > I could probably go with a SHOULD. >=20 > But, I wonder if we are living in the past using the above as > representative of implementations. >=20 > When are we going to start counting cell phones, tablets and other > electronic devices? >=20 > I've seen various stats that say traditional PCs will be a minority of > devices accessing the Internet sometime this year. >=20 > (Of course, the overall percentage of such devices with IPv6 makes the > argument sort of moot, but that's a detail...) To put it another way, if we think there is a good use case for this as = Ole describes, we will be doing a service to the devices that don't have = their IPv6 code yet, to make it a SHOULD so they are more likely to = implement it. Agree? Bob From fred@cisco.com Mon May 9 17:37: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 655A8E0839 for ; Mon, 9 May 2011 17:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.457 X-Spam-Level: X-Spam-Status: No, score=-109.457 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Nj2LEVoQeviR for ; Mon, 9 May 2011 17:37:19 -0700 (PDT) Received: from sj-iport-2.cisco.com (unknown [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7D44CE0778 for ; Mon, 9 May 2011 17:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=195; q=dns/txt; s=iport; t=1304987839; x=1306197439; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=XSxNhTk7VJpoVmeJpy/y5nN3Q6phSqw1PZQRi5h8eFE=; b=OvgP9eNTbHKtWz7ETr1iNe+SFRzJP/MG7YcnDK8TMMdNjBeHaMdzz5lu 4huMvBPBy+54s3CWuee1dIxtGsT1kZrCrn18fpi3NgmtXeO9pQAzkUdDq n2jyi2Fh6wP+wr3o5cIlR1Pej2XTfdhrDBKi/cbSO+xTFhGQ9EMVktNkf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANOHyE2rRDoI/2dsb2JhbACmAXeIcZ50njCGDASGQIkkhCiKVg X-IronPort-AV: E=Sophos;i="4.64,343,1301875200"; d="scan'208";a="353588236" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 10 May 2011 00:37:19 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4A0bDw1009191; Tue, 10 May 2011 00:37:18 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Mon, 09 May 2011 17:37:19 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Mon, 09 May 2011 17:37:19 -0700 Subject: Re: Short 6MAN WG Last Call: Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <201105100015.p4A0FwW3016108@cichlid.raleigh.ibm.com> Date: Mon, 9 May 2011 17:37:03 -0700 Message-Id: References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <1C30F071-AD2E-4D55-9AAD-FCE7629BBC06@gmail.com> <201105100015.p4A0FwW3016108@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 6man Mailing List , Brian Haberman , Bob Hinden 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, 10 May 2011 00:37:20 -0000 On May 9, 2011, at 5:15 PM, Thomas Narten wrote: > When are we going to start counting cell phones, tablets and other = electronic devices? When they start implementing IPv6 at all...= From narten@us.ibm.com Mon May 9 17:49:33 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 90E63E090A for ; Mon, 9 May 2011 17:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.756 X-Spam-Level: X-Spam-Status: No, score=-105.756 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 gOGDIDnPQd2d for ; Mon, 9 May 2011 17:49:33 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id DE48BE06B7 for ; Mon, 9 May 2011 17:49:32 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4A0NJjA018520 for ; Mon, 9 May 2011 20:23:19 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4A0nTRV445710 for ; Mon, 9 May 2011 20:49:29 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4A0nSIJ011100 for ; Mon, 9 May 2011 21:49:29 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-76-148-57.mts.ibm.com [9.76.148.57]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4A0nRlu011069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 21:49:28 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4A0nQiJ016344; Mon, 9 May 2011 20:49:26 -0400 Message-Id: <201105100049.p4A0nQiJ016344@cichlid.raleigh.ibm.com> To: Ole Troan Subject: Re: Short 6MAN WG Last Call: In-reply-to: References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> Comments: In-reply-to Ole Troan message dated "Fri, 06 May 2011 20:54:26 +0200." Date: Mon, 09 May 2011 20:49:26 -0400 From: Thomas Narten Cc: Bob Hinden , 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: Tue, 10 May 2011 00:49:33 -0000 > > Can someone explain to me the rationale for mandating 4191 in 6204? > > What was the scenario that was envisioned that necessitates 4191? > it was the only way we found to keep support for ULA prefixes. the > scenario is if you have a home CPE with ULA enabled, but no upstream > IPv6 connectivity. if that router advertises itself as a router for > default, as opposed to router for ULA, host implementations that > don't do 3484bis, and don't handle ICMPs, will contribute to IPv6 > breakage. e.g. 75 second time outs per TCP connection. Seems to me, the real issue is the following (from RFC 6204): G-4: By default, an IPv6 CE router that has no default router(s) on its WAN interface MUST NOT advertise itself as an IPv6 default router on its LAN interfaces. That is, the "Router Lifetime" field is set to zero in all Router Advertisement messages it originates [RFC4861]. G-5: By default, if the IPv6 CE router is an advertising router and loses its IPv6 default router(s) on the WAN interface, it MUST explicitly invalidate itself as an IPv6 default router on each of its advertising interfaces by immediately transmitting one or more Router Advertisement messages with the "Router Lifetime" field set to zero [RFC4861]. That is, a CPE router with multiple LAN interfaces is not allowed to advertise itself as a default router (when it loses internet connectivity), when that is arguably a fine thing for it to do. I have to wonder whether RFC 6204 has gotten this wrong. It is very CPE centric, assuming it is the only router on the home network. It has conflated the notion of a router being fine as a default router for the hosts attached to the same link (i.e., via RAs) and the the more traditional router notion of default route. I.e., if the CPE router has multiple LAN interfaces, each with a ULA (or other prefix) assigned to it, advertising itself as a default router seems like a perfectly reasonable thing to do. Thomas From bob.hinden@gmail.com Mon May 9 18:25: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 6C8B5E09A0 for ; Mon, 9 May 2011 18:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.531 X-Spam-Level: X-Spam-Status: No, score=-103.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 bdbyyG-7xqoG for ; Mon, 9 May 2011 18:25:45 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7CA8E0931 for ; Mon, 9 May 2011 18:25:45 -0700 (PDT) Received: by pzk5 with SMTP id 5so3513539pzk.31 for ; Mon, 09 May 2011 18:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=yX3m2ErbSH6YFo0WQO1vW9qEojOesjvffizXk+o8ht8=; b=xm5KBwOA69Et5ZOWbS4GX79sCVfzvOFe/rS605hQ0/rAMoY+JhiHISNLG0v2OeJpDh C8YTQW8/vFSCdOK2qLWeOsrmH4uUbA0dtuFGKmrmwuOslCA8AUgYamVKxpZ/KP63Gk02 3cTueJM7TwXp/Z+rvB0opyOzHsQ/AcvSG3nMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=oD8RBBhJ+cUBEbCiLl8gZLbVj4i/gfE0RmzSxyy5sR0AOeDn3upfOl8FGgokWiJnUg GwbCkMtewbX3VSM4rmpZvNZVHKgM+ScbuGDjhvxGfh2eqq0raFjaNCmJbYgzwz/bqRbv 7Dk1HT5MKfBv8xFAWT/azRS5/lAOWEryn4JUs= Received: by 10.142.14.10 with SMTP id 10mr3140583wfn.13.1304989358526; Mon, 09 May 2011 18:02:38 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id x11sm8787604wfd.1.2011.05.09.18.02.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 18:02:37 -0700 (PDT) Subject: Re: Short 6MAN WG Last Call: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Mon, 9 May 2011 18:02:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5957D19A-BCAC-4D23-AC32-3BA306C8CF7E@gmail.com> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <1C30F071-AD2E-4D55-9AAD-FCE7629BBC06@gmail.com> <201105100015.p4A0FwW3016108@cichlid.raleigh.ibm.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: Thomas Narten , 6man Mailing List , Brian Haberman , Bob Hinden 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, 10 May 2011 01:25:46 -0000 On May 9, 2011, at 5:37 PM, Fred Baker wrote: >=20 > On May 9, 2011, at 5:15 PM, Thomas Narten wrote: >=20 >> When are we going to start counting cell phones, tablets and other = electronic devices? >=20 > When they start implementing IPv6 at all... iOS and Symbian appear to do IPv6 pretty well. I think iOS is ahead of = MacOS as it get's updated more often. Not sure about Android, Win7 = phone, and the others. Bob From cb.list6@gmail.com Mon May 9 18:56:24 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 13485E09D1 for ; Mon, 9 May 2011 18:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.021 X-Spam-Level: X-Spam-Status: No, score=-3.021 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 AdssDfpWKxlv for ; Mon, 9 May 2011 18:56:23 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 12C7FE06B7 for ; Mon, 9 May 2011 18:56:22 -0700 (PDT) Received: by eye13 with SMTP id 13so2089719eye.31 for ; Mon, 09 May 2011 18:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=5Fi4vAyIvVt67Et4XO+eahUPU54YYh7Xvk0HtKrDMGk=; b=lnjz4kePgUoPOkcnJ8HANRYfeUMyKwSwy1TVUUGW58MatR3lpbIFZljWe8JBig7jRY +d6o1VuBzTNjpfXquGiZKBtrzxkJ69BI0rBhG5I6JGiuFzS+jUmF1rYSVi/vJ1eTJD7Y MsDWpCrXaiKdTQ32g+IPr6SB3v/0p+KNgj5VI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=gAY/imxNAkzWAPuyV7x9e3PtBHzG5m0KfnryWvWDoF7y0C1ARHjUdI4Wu0Qh02avzA abtUHiPTarFReYMRKR1v/Rz4luwFHjny2nkQKS3huvK/R0qravBWnSNXq170ewHTjjsI wY1tYjNPKK1ovd2twcpFbsYmuTQMmX5TwX1Fo= MIME-Version: 1.0 Received: by 10.14.122.201 with SMTP id t49mr3241803eeh.25.1304992581705; Mon, 09 May 2011 18:56:21 -0700 (PDT) Received: by 10.14.37.143 with HTTP; Mon, 9 May 2011 18:56:21 -0700 (PDT) Received: by 10.14.37.143 with HTTP; Mon, 9 May 2011 18:56:21 -0700 (PDT) Date: Mon, 9 May 2011 18:56:21 -0700 Message-ID: Subject: OT -- Nokia v6 support -- was Re: Short 6MAN WG Last Call: From: Cameron Byrne To: Bob Hinden Content-Type: multipart/alternative; boundary=e0cb4e43d0b744622f04a2e24327 Cc: Thomas Narten , Brian Haberman , 6man Mailing List , Fred Baker 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, 10 May 2011 01:56:24 -0000 --e0cb4e43d0b744622f04a2e24327 Content-Type: text/plain; charset=ISO-8859-1 On May 9, 2011 6:26 PM, "Bob Hinden" wrote: > > > On May 9, 2011, at 5:37 PM, Fred Baker wrote: > > > > > On May 9, 2011, at 5:15 PM, Thomas Narten wrote: > > > >> When are we going to start counting cell phones, tablets and other electronic devices? > > > > When they start implementing IPv6 at all... > > iOS and Symbian appear to do IPv6 pretty well. I think iOS is ahead of MacOS as it get's updated more often. Not sure about Android, Win7 phone, and the others. > Bob > Hate to split hairs and go OT, but while symbian s60 did support ipv6 well, s^3 -- the going forward successor of s60 -- does not support ipv6. New nokia phones like the n8 and c7 do not support ipv6 due to software bugs that make the device unusable and there is no roadmap I am aware of to fix it. It is a terrible step backwards. Cb > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --e0cb4e43d0b744622f04a2e24327 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On May 9, 2011 6:26 PM, "Bob Hinden" <bob.hinden@gmail.com> wrote:
>
>
> On May 9, 2011, at 5:37 PM, Fred Baker wrote:
>
> >
> > On May 9, 2011, at 5:15 PM, Thomas Narten wrote:
> >
> >> When are we going to start counting cell phones, tablets and = other electronic devices?
> >
> > When they start implementing IPv6 at all...
>
> iOS and Symbian appear to do IPv6 pretty well. =A0I think iOS is ahead= of MacOS as it get's updated more often. =A0Not sure about Android, Wi= n7 phone, and the others.
> Bob
>

Hate to split hairs and go OT, but while symbian s60 did support ipv6 we= ll, s^3 -- the going forward successor of s60 -- does not support ipv6. New= nokia phones like the n8 and c7 do not support ipv6 due to software bugs t= hat make the device unusable and there is no roadmap I am aware of to fix i= t. It is a terrible step backwards.=A0

Cb

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

--e0cb4e43d0b744622f04a2e24327-- From hesham@elevatemobile.com Mon May 9 20:06:54 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 F1455E0916 for ; Mon, 9 May 2011 20:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 OKojrVkWAzUu for ; Mon, 9 May 2011 20:06:53 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id F2814E08EC for ; Mon, 9 May 2011 20:06:51 -0700 (PDT) Received: from [124.176.169.232] (helo=[10.0.0.24]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1QJcQz-0000jK-Rl; Tue, 10 May 2011 12:12:26 +1000 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 10 May 2011 12:12:19 +1000 Subject: Re: Short 6MAN WG Last Call: From: Hesham Soliman To: Bob Hinden , Fred Baker Message-ID: Thread-Topic: Short 6MAN WG Last Call: In-Reply-To: <5957D19A-BCAC-4D23-AC32-3BA306C8CF7E@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: Thomas Narten , 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: Tue, 10 May 2011 03:06:54 -0000 > > > >On May 9, 2011, at 5:37 PM, Fred Baker wrote: > >> >> On May 9, 2011, at 5:15 PM, Thomas Narten wrote: >> >>> When are we going to start counting cell phones, tablets and other >>>electronic devices? >> >> When they start implementing IPv6 at all... > >iOS and Symbian appear to do IPv6 pretty well. I think iOS is ahead of >MacOS as it get's updated more often. => They do but I'm not sure that they support it over 3G. I.e., the IPv6 stack is there and functional over WLAN but for some reason (I'm guessing licensing issues related to the 3G chipset) they don't support PDP context IPv6 when I last checked. I'm not talking about Symbian, just iOS > Not sure about Android, Win7 phone, and the others. => They do over wlan, same problem with 3G. I don't know about blackberry, sonyericsson ...etc. Hesham > >Bob > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From swmike@swm.pp.se Mon May 9 22:48:12 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 D3F5FE06C6 for ; Mon, 9 May 2011 22:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] 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 IE0cjjyRR2O1 for ; Mon, 9 May 2011 22:48:12 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 300FDE0724 for ; Mon, 9 May 2011 22:48:10 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E371D9C; Tue, 10 May 2011 07:48:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DF0269A; Tue, 10 May 2011 07:48:06 +0200 (CEST) Date: Tue, 10 May 2011 07:48:06 +0200 (CEST) From: Mikael Abrahamsson To: Bob Hinden Subject: Re: Short 6MAN WG Last Call: In-Reply-To: <5957D19A-BCAC-4D23-AC32-3BA306C8CF7E@gmail.com> Message-ID: References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <1C30F071-AD2E-4D55-9AAD-FCE7629BBC06@gmail.com> <201105100015.p4A0FwW3016108@cichlid.raleigh.ibm.com> <5957D19A-BCAC-4D23-AC32-3BA306C8CF7E@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Tue, 10 May 2011 05:48:12 -0000 On Mon, 9 May 2011, Bob Hinden wrote: > iOS and Symbian appear to do IPv6 pretty well. I think iOS is ahead of > MacOS as it get's updated more often. Not sure about Android, Win7 > phone, and the others. Android 2.3.4 actually has GUI options to configure IPv6 APN, but we have yet to find a phone we can get it working with. Right now we presume it's a baseband issue on the phones we have available. -- Mikael Abrahamsson email: swmike@swm.pp.se From ichiroumakino@gmail.com Tue May 10 00:59: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 908A8E087F for ; Tue, 10 May 2011 00:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 hzVsTw3RMazD for ; Tue, 10 May 2011 00:59:56 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B304EE087C for ; Tue, 10 May 2011 00:59:55 -0700 (PDT) Received: by wwa36 with SMTP id 36so4518718wwa.13 for ; Tue, 10 May 2011 00:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=n0jGZkl0nyVGD5c9dGCWQmYogyUREIR6ZTkDoShANt8=; b=lET6H2BY5M28aYH7bWdJnqZrGGs+AWwAqw5cV9kwkdGDVUbpea6J3/Ln+qUUsyNvak VEE9M3P1PRtwkx6V1I5hJJXS0BetpDziOJok60mpaUV4GDi9YYtuP2yfDKXePHpYeVtm HSAXqVSyHySP3jH9weyqIrbWFap2112nJP094= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=ZAdMwKk03C2XMYa3g3GZMxlSRmFGq+tD1hl42T8OD9vctFQYPl9LVKVY8nkKY9hnRx FiGGs/oSiLYqPyJsVXyRcwmfXAbb+0ZKjlUhWmF3QUNxwLbVKSEfc9Kc88uLpIagofrP 2QrhiMci23PZ5As5WmQSUxFRNwDwkgNOHXrCY= Received: by 10.216.237.138 with SMTP id y10mr998775weq.30.1305014393728; Tue, 10 May 2011 00:59:53 -0700 (PDT) Received: from dhcp-osl-vl300-64-103-53-245.cisco.com (dhcp-osl-vl300-64-103-53-245.cisco.com [64.103.53.245]) by mx.google.com with ESMTPS id y35sm110574weq.39.2011.05.10.00.59.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2011 00:59:52 -0700 (PDT) Sender: Ole Troan Subject: Re: Short 6MAN WG Last Call: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <201105100049.p4A0nQiJ016344@cichlid.raleigh.ibm.com> Date: Tue, 10 May 2011 09:59:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <60DD63A9-95FB-424A-8FC8-E65C2D065E6D@employees.org> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <201105100049.p4A0nQiJ016344@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: Bob Hinden , 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: Tue, 10 May 2011 07:59:57 -0000 Thomas, >>> Can someone explain to me the rationale for mandating 4191 in 6204? >>> What was the scenario that was envisioned that necessitates 4191?=20 >=20 >> it was the only way we found to keep support for ULA prefixes. the >> scenario is if you have a home CPE with ULA enabled, but no upstream >> IPv6 connectivity. if that router advertises itself as a router for >> default, as opposed to router for ULA, host implementations that >> don't do 3484bis, and don't handle ICMPs, will contribute to IPv6 >> breakage. e.g. 75 second time outs per TCP connection. >=20 > Seems to me, the real issue is the following (from RFC 6204): >=20 > G-4: By default, an IPv6 CE router that has no default router(s) on > its WAN interface MUST NOT advertise itself as an IPv6 default > router on its LAN interfaces. That is, the "Router Lifetime" > field is set to zero in all Router Advertisement messages it > originates [RFC4861]. >=20 > G-5: By default, if the IPv6 CE router is an advertising router and > loses its IPv6 default router(s) on the WAN interface, it MUST > explicitly invalidate itself as an IPv6 default router on each > of its advertising interfaces by immediately transmitting one > or more Router Advertisement messages with the "Router > Lifetime" field set to zero [RFC4861]. >=20 > That is, a CPE router with multiple LAN interfaces is not allowed to > advertise itself as a default router (when it loses internet > connectivity), when that is arguably a fine thing for it to do. >=20 > I have to wonder whether RFC 6204 has gotten this wrong. It is very > CPE centric, assuming it is the only router on the home network. It > has conflated the notion of a router being fine as a default router > for the hosts attached to the same link (i.e., via RAs) and the the > more traditional router notion of default route. >=20 > I.e., if the CPE router has multiple LAN interfaces, each with a ULA > (or other prefix) assigned to it, advertising itself as a default > router seems like a perfectly reasonable thing to do. indeed, but unfortunately that causes IPv6 breakage. this is not at all = CPE centric, from the CPE perspective advertising itself as a default = router is obviously not an issue. the problem is host implementations = that have a ULA address and a default route (but no connectivity to the = IPv6 Internet). these hosts will choose IPv6 first when connecting to = dual-stack destinations, this leads to multi-minute time outs. we had some very extensive discussions on this exact point during the = last call of RFC6104. I hope we do not have to rehash those here. cheers, Ole= From arifumi@nttv6.net Tue May 10 04:01: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 23E93E067A for ; Tue, 10 May 2011 04:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.825 X-Spam-Level: X-Spam-Status: No, score=-101.825 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] 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 7X-oKpNHZbdC for ; Tue, 10 May 2011 04:01:22 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id A7793E0681 for ; Tue, 10 May 2011 04:01:20 -0700 (PDT) Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.4/8.14.3) with ESMTP id p4AAwdoq093547; Tue, 10 May 2011 19:58:39 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: draft-ietf-6man-rfc3484-revise@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: <4DC7D1C0.7050708@globis.net> Date: Tue, 10 May 2011 19:59:30 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <13235377-6E06-44F3-AB74-D7A4C3A0871B@nttv6.net> References: <4DBE8E35.7080008@globis.net> <4DC7D1C0.7050708@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org, fujisaki@syce.net 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, 10 May 2011 11:01:23 -0000 I do not see exactly what your problem is. Is it the default policy to be defined in RFC3484bis ? Or, RFC3484's flexibility to prefer/de-prefer ISATAP ? If it's the latter case, you can configure the policy table so that it = de-prefer your own ISATAP prefix. As you mention it, = draft-ietf-6man-addr-select-opt-00 should be a good way to go. If it's the former case, I do not agree to de-prefer ISATAP prefix than = IPv4, because IPv4 does and will bring worse user experience with the = advance of IPv4 address shortage. Best regards, On 2011/05/09, at 20:36, Ray Hunter wrote: > Thank you very much for replying to my message. >=20 > I have copied the 6man mailing list into the reply, plus your original = mail is attached below, as you requested, so as to involve a larger = community in the discussion. >=20 > Yes. You have a humble opinion that ISATAP is equivalent to native = IPv6 and therefore RFC 3484 bis is already adequate to cover all use = cases. >=20 > And I have a different humble opinion, that I like native IPv6, but I = think ISATAP is worse than native IPv4, and this use-case cannot be = coded into RFC3484 bis.=20 >=20 > Both of us may be correct, dependent of the deployment scenario. My = customers generally have excellent native IPv4 networks. I'm sure that = they want to build excellent native IPv6 networks. ANY tunnel is likely = to be worse than their support of either native protocol. And an = automatic tunnel where the end points may physically move (think = traveling users) even more so. >=20 > The point is that my humble opinion cannot be encoded into RFC3484 bis = as proposed. Indeed I cannot configure any implementation of ISATAP that = I know of today to behave as I desire. I have no way of controlling the = relative preference of native IPv6, versus IPv6 over ISATAP over IPv4, = versus native IPv4.=20 >=20 > I can either prefer all IPv6 above all IPv4, or all IPv4 above all = IPv6. But I can't get any more granular than that. That to my mind is = not enough, because we do not know the exact deployment decisions that = are going to be made by all network managers in the move to IPv6. The = 6man WG can assume that ISATAP is equivalent to native IPv6, but some = others may conclude otherwise. >=20 > I have posted elsewhere about my opinions on the lack of adequate = control in ISATAP in the v6ops WG in reply to the draft = http://tools.ietf.org/html/draft-templin-v6ops-isops-00=20 >=20 > To summarise: Because ISATAP is a host to gateway tunnel, it has no = in-built way of controlling/ limiting additional network latency, nor of = correctly applying DSCP QoS settings, nor can it be filtered by today's = firewalls in a granular manner. So ISATAP is certainly not equivalent to = native IPv6 in my mind. It also relies heavily on management of one = particular DNS / WINS name space content (which may be dynamically = updated as part of standard Windows AD operation), which IMHO is no way = to control a network. One inquisitive/ incompetent server admin setting = his Windows server name to "isatap" can change the behavior of 10000+ = nodes on an international corporate network. That's not my definition of = "managed." So my conclusion is that I have to switch ISATAP off, = everywhere, until those shortcomings are addressed. >=20 > I'm not asking the 6man WG to "fix" the shortcomings of ISATAP, = although that would be nice. >=20 > All I'm asking you guys to consider is whether your RFC3484 bis draft = is complete if it cannot encode ALL combinations of preferences = regarding which native network protocol or transition mechanism to = prefer over another. The IETF does not control or mandate all deployment = scenarios. Nor should it. >=20 > In particular I ask you to further examine supporting the use case: = native IPv6 >> native IPv4 >> IPv6 over ISATAP over IPv4. >=20 > BTW just to say something very positive: the extension of RFC3484 bis = to include ISATAP prioritization + DHCP(v6) distribution would likely be = an extremely useful mechanism for controlling default end node behaviour = in multinational companies (where AD may not be universally deployed). = So keep up the good work in = http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-00 >=20 > best regards, > RayH >=20 > Arifumi Matsumoto wrote: >> Ray, >>=20 >> On 2011/05/02, at 19:57, Ray Hunter wrote: >>=20 >> =20 >>=20 >>> Appreciate your work on RFC3484 bis. I sent a comment regarding = http://www.ietf.org/id/draft-ietf-6man-rfc3484-revise-02.txt >>> via the IETF web site, but I have a suspicion it black-holed. >>>=20 >>> Excuse me if I'm barking up the wrong tree here. Also forgive me if = I'm wrong because interpreting some of these rules confuse me a lot. >>> =20 >>>=20 >>=20 >> These addresses are good. But, the ietf mailing list 6man may be even = more better in that you can gather comments from more people. >>=20 >> =20 >>=20 >>> ISATAP (RFC5214) uses an IPv6 node identifier (based on an IPv4 = address) that is appended to a standard IPv6 /64 prefix to create an = IPv6 overlay network over an existing IPv4 network. So far so good, it = provides IPv6 connectivity over IPv4 to IPv6 only hosts. >>>=20 >>> But what about dual stack hosts? >>>=20 >>> Given that you have now concluded that 6to4 is bad, and Teredo is = even worse, because it is based on a transition mechanism that works = over a dynamic tunnel, shouldn't IPv6 over ISATAP be similarly assigned = a low priority compared to native IPv4? >>> =20 >>>=20 >>=20 >> I do not think all the transition mechanisms should be = less-preferred. >> 6to4 and Teredo are un-managed transition mechanisms, so they are = less-preferred for that reason. >> IMO, ISATAP is deployed and controlled by a site administrator who = may be ISP or enterprise network admin. >> So, I do not think it is unmanaged. >>=20 >> =20 >>=20 >>> In Microsoft's book "Understanding IPv6 v2" on page 219-221, they = even give an example showing how ISATAP combined with a global unique = IPv6 unicast prefix would be preferred over native IPv4. >>>=20 >>> I can't imagine a single case of a dual stack host that would get = better performance using IPv6 over ISATAP over IPv4 than it would get = over a native IPv4 connection. Unless we are in the last days of IPv4, = and there really are only IPv4 islands left. >>> =20 >>>=20 >>=20 >> Just like 6rd, IPv6 may not be better than IPv4 with regard to MTU. >> However that point alone should not be a reasonable motivation to = de-prioritize IPv6. >>=20 >> =20 >>=20 >>> Then again, I'm not at all sure how you could handle that in a = RFC3484 bis type policy table, given that ISATAP does not conform to the = comfortable notion that all mechanisms are left-anchored in the = addressing scheme / are IPv6 prefix length based. >>>=20 >>> Maybe the whole mechanism needs a review? >>>=20 >>> Or ISATAP needs moving to historic status? >>> =20 >>>=20 >>=20 >> RFC3484-bis does not include any changes with regard to ISATAP. >> And, as I mentioned above, IMO ISATAP should be just treated like = global IPv6 addresses. >>=20 >> Best regards, >>=20 >> -- >> Arifumi Matsumoto >> NGN System Architecture Project >> NTT Service Integration Laboratories >> E-mail:=20 >> arifumi@nttv6.net >>=20 >> TEL +81-422-59-3334 FAX +81-422-59-6364 >>=20 >> =20 >>=20 >=20 -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From Wesley.E.George@sprint.com Tue May 10 05:10:13 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 2D52AE0680 for ; Tue, 10 May 2011 05:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.992 X-Spam-Level: X-Spam-Status: No, score=-3.992 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 QjJ4BNsCPPtb for ; Tue, 10 May 2011 05:10:09 -0700 (PDT) Received: from AM1EHSOBE004.bigfish.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id F0484E06B5 for ; Tue, 10 May 2011 05:09:43 -0700 (PDT) Received: from mail69-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.22; Tue, 10 May 2011 12:09:42 +0000 Received: from mail69-am1 (localhost.localdomain [127.0.0.1]) by mail69-am1-R.bigfish.com (Postfix) with ESMTP id 6A4024881B3; Tue, 10 May 2011 12:09:42 +0000 (UTC) X-SpamScore: -44 X-BigFish: VS-44(zz936eK9371O542M1432N98dKzz1202hzz1033IL8275bh8275dh8275chz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:144.229.32.56; KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm1.corp.sprint.com; RD:smtpda1.sprint.com; EFVD:NLI Received-SPF: pass (mail69-am1: domain of sprint.com designates 144.229.32.56 as permitted sender) client-ip=144.229.32.56; envelope-from=Wesley.E.George@sprint.com; helo=pdaasdm1.corp.sprint.com ; p.sprint.com ; Received: from mail69-am1 (localhost.localdomain [127.0.0.1]) by mail69-am1 (MessageSwitch) id 130502938219998_19504; Tue, 10 May 2011 12:09:42 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.244]) by mail69-am1.bigfish.com (Postfix) with ESMTP id 016C5109004E; Tue, 10 May 2011 12:09:42 +0000 (UTC) Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 10 May 2011 12:09:41 +0000 Received: from PLSWEH02.ad.sprint.com (PLSWEH02.corp.sprint.com [144.226.242.131]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p4AC9d4I032164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 May 2011 07:09:39 -0500 Received: from PDAWM12B.ad.sprint.com ([fe80::64c8:fd69:1029:79b0]) by PLSWEH02.ad.sprint.com ([2002:90e2:f283::90e2:f283]) with mapi id 14.01.0270.001; Tue, 10 May 2011 07:09:39 -0500 From: "George, Wes E [NTK]" To: John Leslie , Brian E Carpenter Subject: RE: Flow label drafts updated Thread-Topic: Flow label drafts updated Thread-Index: AQHMDp0FVbAodKQBukmtFXIxQP9WbZSFd9CAgACA9HA= Date: Tue, 10 May 2011 12:09:38 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C919DB@PDAWM12B.ad.sprint.com> References: <4DC07A80.2030200@gmail.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C8F608@PDAWM12B.ad.sprint.com> <4DC721EF.70002@gmail.com> <9DAEFCBC-9814-49BA-AA0A-ED478CF0E8A9@gmail.com> <4DC8720E.3030601@gmail.com> <20110509232707.GL49185@verdi> In-Reply-To: <20110509232707.GL49185@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.62] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002F_01CC0EE9.9ABDA370" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: RJ Atkinson , "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: Tue, 10 May 2011 12:10:13 -0000 ------=_NextPart_000_002F_01CC0EE9.9ABDA370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 - this articulates my concerns and what I'd like to see done to resolve. Wes George -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of John Leslie Sent: Monday, May 09, 2011 7:27 PM To: Brian E Carpenter Cc: ipv6@ietf.org; RJ Atkinson Subject: Re: Flow label drafts updated Brian E Carpenter wrote: > On 2011-05-10 01:02, RJ Atkinson wrote: > >> A much more reasonable approach would be to say (edit to taste): >> >> "The Flow Label SHOULD NOT be changed in transit." > > The authors really need to hear that from more than one person, or to > hear from the WG Chairs that it's a consensus, because it goes against > several months of discussion. I agree with Ran that SHOULD NOT is more appropriate for this case where the horse has long since left the barn. Middleboxes _are_ going to clear it (or worse). OTOH, I don't actually _object_ to MUST NOT -- in the narrow sense that any node that disobeys the MUST NOT isn't speaking the protocol as defined. I do believe we should, regardless, excise all use of the word "immutable" for the Flow Label. That word isn't helping. > I suggest squaring this circle by retaining the MUST NOT (which IMHO > is the present consensus) but making it clear in the security > considerations that there will be exceptions. The problem here is that > the RFC 2119 language doesn't provide MUST NOT UNLESS..., which is > what we really need. SHOULD NOT is not perceived as strong enough. I could live with that; but I really do suggest wordsmithing the 3 uses of "immutable". Additionally, I'd like to see some treatment of what may go wrong if middleboxes change the Flow Label. If I understand, it will partly break load-balancing. Middlebox designers probably don't understand this issue. (Even if they did, they'd likely say, "some users are entirely willing to accept that tradeoff.") -- John Leslie -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------=_NextPart_000_002F_01CC0EE9.9ABDA370 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxMDEy MDkzN1owIwYJKoZIhvcNAQkEMRYEFNQ8g/5bBg1t3i+s5dDUi23/fGeMMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgI5VjeDPYc39oVgXeRI/KOfwrV13Ehsa8bvvSl7ihhj+FWgHcc0gXajgQ+S4TpqNRQK1 +dgNzl0B8QoK4ALI4t8sJrKh53EVhIEWR0vmT3HJBai8gmJfBtyzXkoRfqO4Pux3DOgK66h79FOH 7tEk0qPu8jiMV3oix82dRO54LfhHAAAAAAAA ------=_NextPart_000_002F_01CC0EE9.9ABDA370-- From ran.atkinson@gmail.com Tue May 10 05:38: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 6017BE0789 for ; Tue, 10 May 2011 05:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 WJBfq1Pnt5OB for ; Tue, 10 May 2011 05:38:47 -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 76F86E07D2 for ; Tue, 10 May 2011 05:38:47 -0700 (PDT) Received: by vws12 with SMTP id 12so573888vws.31 for ; Tue, 10 May 2011 05:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=Wyb8cjhZpnyGslEdpqy9Fw4ooM57uAa09r6HBG6x6HY=; b=Jp0KdJ90Bdj+cnj+HSc7cAMd2hK/d8GQMfI7Z8YDlUU3OVNVLyhsn+aZi5nCtnrVxj q2GrErm8XZsLXgSzUbHVUNERilssZp9X8CmfdRU/aLZ6uizoii7KstgUk7RLok0Jn67G 4WZSj4ryzZSx3xVYdxfJl1SulKKQL3Ksu1d4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=c1zfa1AWv3ZlWacCIDb7/P57aHIvLS6MFNyg/3iKGvfDkUrBZ3Tg8Xk03lU6/pMSR1 zm8rUKtNY3TJwRQ25gP0cpg+p6O+3oc2XRAr6z4VBSI6dTpYvMm+PupqjgNIiH9qY2CA LMCRjKJaqP7OcDA3eXU9xcjt+Z09AH+yEzSJo= Received: by 10.52.111.131 with SMTP id ii3mr103506vdb.235.1305031126195; Tue, 10 May 2011 05:38:46 -0700 (PDT) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id h23sm2662983vbz.9.2011.05.10.05.38.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2011 05:38:45 -0700 (PDT) From: Ran Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Flow label drafts updated Date: Tue, 10 May 2011 08:38:42 -0400 Message-Id: <9D6E0FDC-A5BA-4D19-B49A-939E0330DF08@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 10 May 2011 12:38:48 -0000 Earlier, Brian Carpenter wrote: > I suggest squaring this circle by retaining the MUST NOT (which IMHO > is the present consensus) but making it clear in the security > considerations that there will be exceptions. The problem here is that > the RFC 2119 language doesn't provide MUST NOT UNLESS..., which is > what we really need. SHOULD NOT is not perceived as strong enough. My understanding is that the "...MUST NOT..., unless ..." language is acceptable procedurally -- PROVIDED the unless is crisply and narrowly defined. RFC-2119 does not prohibit that language. Certainly I understand that language has been used in the past by this community, albeit not frequently. I've checked with a few other folks, who have the same view on that language being acceptable (provided the exceptions are crisply/narrowly defined), if infrequent, usage. I'm quite happy with the compromise you put forward above, and since the exceptions are quite narrow and precise, I propose that the I-D(s) use the "MUST NOT ... unless" construct. Here is a starting point on some text. Please edit to taste: The Flow Label MUST NOT be changed in transit, unless (a) a router is changing a zero value Flow Label to a non-zero value Flow Label compliant with this RFC or (b) a security gateway for operational security reasons changes a non-zero value Flow Label to a different non-zero value Flow Label compliant with this RFC. I believe that security gateways overtime will become compliant with this new specification if we provide them the instructions above. Yours, Ran ran.atkinson@gmail.com From v6ops@globis.net Tue May 10 08:01:24 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 8B98FE0681 for ; Tue, 10 May 2011 08:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.842 X-Spam-Level: X-Spam-Status: No, score=-2.842 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] 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 xQmH2FFBGBMY for ; Tue, 10 May 2011 08:01:17 -0700 (PDT) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id C9F7FE0659 for ; Tue, 10 May 2011 08:01:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0056D8700E1; Tue, 10 May 2011 17:01:14 +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 Ca2qo7I7tIgw; Tue, 10 May 2011 17:01:07 +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 90E99870067; Tue, 10 May 2011 17:01:07 +0200 (CEST) Message-ID: <4DC95325.7000009@globis.net> Date: Tue, 10 May 2011 17:00:53 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Arifumi Matsumoto Subject: Re: draft-ietf-6man-rfc3484-revise@tools.ietf.org References: <4DBE8E35.7080008@globis.net> <4DC7D1C0.7050708@globis.net> <13235377-6E06-44F3-AB74-D7A4C3A0871B@nttv6.net> In-Reply-To: <13235377-6E06-44F3-AB74-D7A4C3A0871B@nttv6.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, fujisaki@syce.net 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, 10 May 2011 15:01:24 -0000 Thanks. You have answered my basic question in that it is possible to encode individual ISATAP subnet prefixes, and I accept that'll probably work for most people (together with the assumption that RFC1918 IPv4 + NAT is now "global.") I'm just trying to explore the boundaries and assumptions here via use cases. If it isn't helpful to you, just let me know. The only mechanism that I know of for selecting between the preference order for alternative encapsulations is RFC 3484 (and your proposed RFC 3484 bis) or hard coding. All initiatives so far seem to make certain assumptions about the desirability of various preferences. (e.g. paraphrasing some history: IPv4 is going to be awful so prefer IPv6). We can discuss requirements and defaults, but I think a discussion on flexibility and being able to over ride the default might also be useful. The reason that this has an impact on network managers, as I'm sure you're aware, is that although there is often a fall back mechanism to a different encapsulation method, this fall back takes a finite amount of time, which may or may not be an operational problem depending on a particular SLA. See e.g. happy eyeballs, although I can think of more extreme examples like control and trading systems where certain protocols require a different preference setting. So being able to tightly manage the selection preference order could be critical to some network managers. I don't have a real "problem" with the current default for ISATAP. I find it unfortunate for my particular needs that I can think of today, that's all. Different people have different requirements and SLA'a and transition paths. We are very early in the transition to IPv6 and I read all sorts of assumptions and debates on various blogs about the suitability of various preference schemes and protocols. In reality I'm not sure anyone knows the "correct" answer at this time, and certainly not the "single correct answer." The reality is that transition will probably be a process. RFC3484 was probably the "right thing to do" at the time, but I think we all agree it needs at least some updating. Once again thanks for taking the lead in this. I certainly recognise that any one version of requirements may not be universal. In fact I acknowledge that the version I have presented is probably more driven by latency SLA's than most. Some people may want a use case of native IPV6 >> native IPv4 >> tunnel protocols if they want to build networks with great IPv6 connectivity whilst keeping native IPv4 in production if they have certain SLA issues and requirements. The opposite case may also be true for people who have great IPv4 connectivity, but that their native IPv6 connectivity is somehow broken (I can think of a local CPE router which advertises IPv6, but the intermediate native IPv6 connectivity is broken due to a non-conformant device e.g. firewall) So people may actually prefer a tunnel over IPv4 versus a native protocol. That use case would be particular_tunnel_protocol >> native IPv4 >> native IPV6 Some people use RFC 1918 address on their local LANs. Others use PI IPv4 space (Teredo makes an assumption that PI addresses space = Internet and RC1918 = private LAN. Again an assumption that is not always true.) I can also think of other tunnel encapsulation technologies like IPv6 IPSec over blah (Microsoft directAccess), IPv6 over GRE over blah, 6rd, IP-HTTPS ..... I now understand the workaround for my specific ISATAP case: to encode each ISATAP prefix individually in the prefix table. Thanks. First follow up question on implementation detail: Do you think this solution will be sufficiently scalable for larger environments? e.g. If there were 200+ ISATAP routers. I'm not sure the prefix policy table would still work efficiently if it had to be scanned before every session start up. Maybe it would. I don't know. Do you have some operational experience on the limits? Or is this way out of scope of the WG? I also recognize that requirements will probably change over time. Second more generic follow up question: Your draft suggests that RFC 1918 IPv4 addresses should now be considered global. I have read that some earlier implementations consider them local. There are arguments for both views. So even if the ISATAP (global) IPv6 range was encoded with a lower priority than IPv4 in an old implementation, my understanding is that Rule 2 of source selection in RFC3484 would over ride that and prefer an IPv6 address. So the prefix table would effectively be ignored in this case. RFC3484 bis clarifies (and "fixes") this by suggesting that RFC 1918 address is global. That works for my use case today. But is this future proof? I think that this assumes that RFC1918 addresses are also connected to the global IPv4 internet via NAT. I realise that this again is probably a no-win case. Corporations who have implemented RFC 1918+ NAT probably can consider RFC1918 to be equivalent to global. But one day we may very well end up with islands of IPv4 connectivity in an IPv6 global Internet, with RFC1918 once again reverting to local scope. Similarly there's a debate about whether to deprecate the 6to4 address range in http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic-02. (perhaps including a phase out plan so there might be no one universal set date for all network operators). One way of achieving that is reducing the preference. Another is hard coding 6to4 as "deprecated." A third would be to make detecting an address as deprecated a user configurable setting with a default (thus allowing the flexible roll out date). In the ISATAP use case, I guess I was hoping for a single setting based on selecting preference by "encapsulation type=ISATAP" with address range = "don't care" that could be rolled out to all nodes, rather than adding multiple address prefix ranges. This may or may not be operationally practicable within the existing structure of RFC3484. Are these examples adding up to an argument that the RFC 3484 bis mechanism needs some sort of extension to allow network managers themselves to make more of the changes via configuration, rather than via code? Considering that different groups will take different transition paths at different times? I understand of course there is a balance to be struck somewhere, and not everything can be configuration. I also don't want to derail your work (which as I am already on record as stating is very positive), but maybe you might like to consider a restructuring of the (notional) RFC3484 bis table(s) to include not only the prefix in the address selection table, but also to cover perhaps the other different address "types" identified in section 3 of RFC3484: i) whether an address range is deprecated [rfc3484 rule 3 of destination selection] ii) the encapsulation method that would be used with this address, 6to4, native, ISATAP, IPSec, blah [rfc3484 rule 7 destination address] iii) the scope classification for a range as interface-local, link-local, admin-local, site-local, organization-local or global [RFC3484 rule 2 source address] ...... to make the selection rules more configurable, whilst keeping the rules themselves invariant. One way of achieving this might be to specify that the prefix policy table may have an additional columns which is by default "don't care" and which could be expanded later to include the exceptions/ difficult cases. Or that the single prefix policy table is augmented by additional policy tables to cover the classification of the other address "types" e.g. a (notional) table that translates prefix range to scope. Maybe this is just a completely new piece of work / RFC. Maybe these are such an off the wall cases that you decide that it isn't worth investigating further at this time. I leave that choice to you. But I do have a feeling that it could help future proof the implementations and give more granularity to individual network managers to implement RFC3484 bis table contents as they see fit, whilst still allowing the IETF WG to suggest useful defaults. The bottom line I guess is whether you are convinced that all potential use cases for the coming X years are already covered. Once again, thanks for your efforts. regards, RayH Arifumi Matsumoto wrote: > Or, RFC3484's flexibility to prefer/de-prefer ISATAP ? From brian.e.carpenter@gmail.com Tue May 10 15:03:14 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 EB96CE06F0 for ; Tue, 10 May 2011 15:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 anEjdFuA-ujW for ; Tue, 10 May 2011 15:03:14 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6EBC8E06D9 for ; Tue, 10 May 2011 15:03:14 -0700 (PDT) Received: by pxi2 with SMTP id 2so4131908pxi.38 for ; Tue, 10 May 2011 15:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bZAnMooZoOVacH9tfmmor1iaA5r11mMqHAMOE8jQwCQ=; b=WsMNxr3TayzNgF8+O4a45vK3r6P5tsA1lsLDmK8EutOLB1kWB02st+QKPM6H2fNMce qwkfszvWnarqeGvTSNErgj1GNN9A+YwT2glkCz6vw5PQPu479sdptzrqNE7Qz5uqwdNV UmNOyVQOdiSGDOQqwYkYsBwBXljNQpWGS5Sig= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=ooXS4tQ4wcSaNXQrpdflgVx497lbz3nVAHltxUNHlI4UgcAFIB24Vo4UBvWUXh8dJW AGOrr1FGf5pq0SVa/x0VcZUsl90TvcW373rZWXv3KyCZ+P3Hl3AcxL2Pb1mo6RO5rkMP p/JGKbWC83iWJSg138iAn0pPw+IrpbS3y3Jow= Received: by 10.68.46.65 with SMTP id t1mr2855904pbm.231.1305063636203; Tue, 10 May 2011 14:40:36 -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 l7sm2785539pbs.55.2011.05.10.14.40.34 (version=SSLv3 cipher=OTHER); Tue, 10 May 2011 14:40:35 -0700 (PDT) Message-ID: <4DC9B0D0.9010900@gmail.com> Date: Wed, 11 May 2011 09:40:32 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ran Atkinson Subject: Re: Flow label drafts updated References: <9D6E0FDC-A5BA-4D19-B49A-939E0330DF08@gmail.com> In-Reply-To: <9D6E0FDC-A5BA-4D19-B49A-939E0330DF08@gmail.com> Content-Type: text/plain; charset=UTF-8 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: Tue, 10 May 2011 22:03:15 -0000 On 2011-05-11 00:38, Ran Atkinson wrote: > Earlier, Brian Carpenter wrote: >> I suggest squaring this circle by retaining the MUST NOT (which IMHO >> is the present consensus) but making it clear in the security >> considerations that there will be exceptions. The problem here is that >> the RFC 2119 language doesn't provide MUST NOT UNLESS..., which is >> what we really need. SHOULD NOT is not perceived as strong enough. > > My understanding is that the "...MUST NOT..., unless ..." language > is acceptable procedurally -- PROVIDED the unless is crisply and > narrowly defined. RFC-2119 does not prohibit that language. > Certainly I understand that language has been used in the past > by this community, albeit not frequently. I've checked with a few > other folks, who have the same view on that language being > acceptable (provided the exceptions are crisply/narrowly defined), > if infrequent, usage. > > I'm quite happy with the compromise you put forward above, > and since the exceptions are quite narrow and precise, > I propose that the I-D(s) use the "MUST NOT ... unless" construct. > > Here is a starting point on some text. Please edit to taste: > > The Flow Label MUST NOT be changed in transit, unless > (a) a router is changing a zero value Flow Label to > a non-zero value Flow Label compliant with this RFC > or (b) a security gateway for operational security > reasons changes a non-zero value Flow Label to a > different non-zero value Flow Label compliant with this RFC. > > I believe that security gateways overtime will become compliant > with this new specification if we provide them the instructions > above. Ran, this looks fine to me, subject to wordsmithing when I see it in context, and to adding a real discussion of covert channels in the Security Considerations. Of course I will have to seek the agreement of my co-authors and resolve the other recent comments (mainly from Thomas), so expect a few more days before we have a new draft. Thanks for your help in getting this right. Brian From v6ops@globis.net Wed May 11 00:11: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 CACB1E075B for ; Wed, 11 May 2011 00:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 pVREGbCDxC2G for ; Wed, 11 May 2011 00:11:00 -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 1C630E06C1 for ; Wed, 11 May 2011 00:10:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C9EB28700B0; Wed, 11 May 2011 09:10:58 +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 57l0lGBNI0KR; Wed, 11 May 2011 09:10:52 +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 2D3F587005C; Wed, 11 May 2011 09:10:52 +0200 (CEST) Message-ID: <4DCA367C.9070103@globis.net> Date: Wed, 11 May 2011 09:10:52 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Arifumi Matsumoto Subject: Re: draft-ietf-6man-rfc3484-revise@tools.ietf.org References: <4DBE8E35.7080008@globis.net> <4DC7D1C0.7050708@globis.net> <13235377-6E06-44F3-AB74-D7A4C3A0871B@nttv6.net> In-Reply-To: <13235377-6E06-44F3-AB74-D7A4C3A0871B@nttv6.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, fujisaki@syce.net 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, 11 May 2011 07:11:00 -0000 Arifumi Matsumoto wrote: > I do not see exactly what your problem is. > Ah. Maybe the light bulb has gone on at my end about a possible disconnect in requirements after having read RFC 5220 and RFC 5221 and the discussion thread from 2005 here http://www.ietf.org/mail-archive/web/ipv6/current/msg05566.html. In these days of BYOD (bring your own device), exploding numbers of mobile devices, embedded devices, and traveling users, I feel there is a need for a standardized non-proprietary way for a transport network manager to be able to signal to end nodes (that may not be under his direct administrative management) what is appropriate behavior when connected to this particular transport network. The usage case I had thought about for RFC 3484 in one sentence was "to allow a transport network manager to provide hints to end nodes so that the end nodes could optimize the selection order of various network encapsulations when there were multiple choices available, in order to reduce the number of unsuccessful session establishment attempts which would lead to fall back to another encapsulation, thus reducing overall session establishment time, leading to happier users, and to be able to ensure compliance with an SLA e.g. by avoiding additional latency introduced by tunnels." Does that explain the "problem" and help put my questions in context? regards, RayH From narten@us.ibm.com Wed May 11 14:13:15 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 A16CCE06E7 for ; Wed, 11 May 2011 14:13:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AMmSS-fZ5p9 for ; Wed, 11 May 2011 14:13:15 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 14A96E06AE for ; Wed, 11 May 2011 14:13:15 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4BL1nRC027732 for ; Wed, 11 May 2011 15:01:49 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4BLCxsx097284 for ; Wed, 11 May 2011 15:12:59 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4BFCWtd021481 for ; Wed, 11 May 2011 09:12:32 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-76-136-152.mts.ibm.com [9.76.136.152]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4BFCU4D021344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 May 2011 09:12:31 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4BLCt4c011220; Wed, 11 May 2011 17:12:56 -0400 Message-Id: <201105112112.p4BLCt4c011220@cichlid.raleigh.ibm.com> To: Ole Troan Subject: Re: Short 6MAN WG Last Call: In-reply-to: <60DD63A9-95FB-424A-8FC8-E65C2D065E6D@employees.org> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <201105100049.p4A0nQiJ016344@cichlid.raleigh.ibm.com> <60DD63A9-95FB-424A-8FC8-E65C2D065E6D@employees.org> Comments: In-reply-to Ole Troan message dated "Tue, 10 May 2011 09:59:49 +0200." Date: Wed, 11 May 2011 17:12:55 -0400 From: Thomas Narten Cc: 6man Mailing List , Brian Haberman , Bob Hinden 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, 11 May 2011 21:13:15 -0000 Ole Troan writes: > > That is, a CPE router with multiple LAN interfaces is not allowed to > > advertise itself as a default router (when it loses internet > > connectivity), when that is arguably a fine thing for it to do. > > > > I have to wonder whether RFC 6204 has gotten this wrong. It is very > > CPE centric, assuming it is the only router on the home network. It > > has conflated the notion of a router being fine as a default router > > for the hosts attached to the same link (i.e., via RAs) and the the > > more traditional router notion of default route. > > > > I.e., if the CPE router has multiple LAN interfaces, each with a ULA > > (or other prefix) assigned to it, advertising itself as a default > > router seems like a perfectly reasonable thing to do. > indeed, but unfortunately that causes IPv6 breakage. this is not at > all CPE centric, from the CPE perspective advertising itself as a > default router is obviously not an issue. the problem is host > implementations that have a ULA address and a default route (but no > connectivity to the IPv6 Internet). these hosts will choose IPv6 > first when connecting to dual-stack destinations, this leads to > multi-minute time outs. Let me be sure I understand. Which 3484 rule comes into play that has an impact here? Is it: Rule 1: Avoid unusable destinations. If DB is known to be unreachable or if Source(DB) is undefined, then prefer DA. Similarly, if DA is known to be unreachable or if Source(DA) is undefined, then prefer DB. I.e., if trying to reach a site, and the IPv6 address is "unreachable" per above, choose the v4 address? (Sounds great in theory!). So the CPE rule that says you MUST NOT advertise yourself as a default router if you don't have real IPv6 connectivity is intended to result in all destinations (other than local ones) showing up as "unreachable" when the above rule happens? Is this the intention, or am I looking at the wrong scenario here? > we had some very extensive discussions on this exact point during > the last call of RFC6104. I hope we do not have to rehash those > here. I'll try not to. :-) Thomas From ichiroumakino@gmail.com Wed May 11 14:19:11 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 9931BE0828 for ; Wed, 11 May 2011 14:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 3ABhctkmq0Vq for ; Wed, 11 May 2011 14:19:11 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B77CAE0812 for ; Wed, 11 May 2011 14:19:10 -0700 (PDT) Received: by ewy19 with SMTP id 19so326892ewy.31 for ; Wed, 11 May 2011 14:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=/i3XJ4331h0ykJVM1ReQfiAhk5O9AfU2xyBe7ty3A64=; b=EfnhDC0D6/VfrcAqqMdnEs1rMcaxfs1yP8ieZp7MS6FJzjSp05mSwHgGRf57qo6lpL wVWggq+vR0TkqZLTn1REAApR8dxxDJEwPjipjzT5tF7JDtp+O6fhLxjVgnBfsCq4OGhr xU6JxCiPwYdUzg8mJaOVu0Bygcb3rSQtgvBus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=om20yMQ7Bo8BBACM47qe4iPupU6vbtKclytxvKU3YsVPf+ikQ7GmkX8QxGb1r73I8C T8IwQTkdUm3iSW1EoX8xebuNMmbAELFlyXpKpUF7HxbCizJmks+jrr0iZ1iuaaXDZWJV o5iRZx9isqeVvTx6rlSpOC7X5XE5pwPe/iFUQ= Received: by 10.213.26.152 with SMTP id e24mr3677085ebc.125.1305148749597; Wed, 11 May 2011 14:19:09 -0700 (PDT) Received: from gomlefisk.cisco.com (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id y9sm222233eeh.22.2011.05.11.14.19.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 14:19:08 -0700 (PDT) Sender: Ole Troan Subject: Re: Short 6MAN WG Last Call: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <201105112112.p4BLCt4c011220@cichlid.raleigh.ibm.com> Date: Wed, 11 May 2011 23:19:06 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <201105100049.p4A0nQiJ016344@cichlid.raleigh.ibm.com> <60DD63A9-95FB-424A-8FC8-E65C2D065E6D@employees.org> <201105112112.p4BLCt4c011220@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: 6man Mailing List , Brian Haberman , Bob Hinden 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, 11 May 2011 21:19:11 -0000 Thomas, >>> That is, a CPE router with multiple LAN interfaces is not allowed to >>> advertise itself as a default router (when it loses internet >>> connectivity), when that is arguably a fine thing for it to do. >>> >>> I have to wonder whether RFC 6204 has gotten this wrong. It is very >>> CPE centric, assuming it is the only router on the home network. It >>> has conflated the notion of a router being fine as a default router >>> for the hosts attached to the same link (i.e., via RAs) and the the >>> more traditional router notion of default route. >>> >>> I.e., if the CPE router has multiple LAN interfaces, each with a ULA >>> (or other prefix) assigned to it, advertising itself as a default >>> router seems like a perfectly reasonable thing to do. > >> indeed, but unfortunately that causes IPv6 breakage. this is not at >> all CPE centric, from the CPE perspective advertising itself as a >> default router is obviously not an issue. the problem is host >> implementations that have a ULA address and a default route (but no >> connectivity to the IPv6 Internet). these hosts will choose IPv6 >> first when connecting to dual-stack destinations, this leads to >> multi-minute time outs. > > Let me be sure I understand. Which 3484 rule comes into play that has > an impact here? Is it: > > Rule 1: Avoid unusable destinations. > If DB is known to be unreachable or if Source(DB) is undefined, then > prefer DA. Similarly, if DA is known to be unreachable or if > Source(DA) is undefined, then prefer DB. > > I.e., if trying to reach a site, and the IPv6 address is "unreachable" > per above, choose the v4 address? (Sounds great in theory!). So the > CPE rule that says you MUST NOT advertise yourself as a default router > if you don't have real IPv6 connectivity is intended to result in all > destinations (other than local ones) showing up as "unreachable" when > the above rule happens? > > Is this the intention, or am I looking at the wrong scenario here? that is indeed the intention. this also appears to work well regardless of a node implementing 3484 or not. >> we had some very extensive discussions on this exact point during >> the last call of RFC6104. I hope we do not have to rehash those >> here. > > I'll try not to. :-) thanks. ;-) cheers, Ole From ipng@69706e6720323030352d30312d31340a.nosense.org Wed May 11 15:16: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 592C9E07F4 for ; Wed, 11 May 2011 15:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 qibQFWoWP29W for ; Wed, 11 May 2011 15:16:44 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 64E9CE0870 for ; Wed, 11 May 2011 15:16:44 -0700 (PDT) Received: from 219-90-162-60.ip.adam.com.au ([219.90.162.60] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QKHhl-00063j-4M; Thu, 12 May 2011 07:46:29 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id BE7A93B338; Thu, 12 May 2011 07:46:28 +0930 (CST) Date: Thu, 12 May 2011 07:46:28 +0930 From: Mark Smith To: Thomas Narten Subject: Re: Short 6MAN WG Last Call: Message-ID: <20110512074628.387685dd@opy.nosense.org> In-Reply-To: <201105112112.p4BLCt4c011220@cichlid.raleigh.ibm.com> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <201105100049.p4A0nQiJ016344@cichlid.raleigh.ibm.com> <60DD63A9-95FB-424A-8FC8-E65C2D065E6D@employees.org> <201105112112.p4BLCt4c011220@cichlid.raleigh.ibm.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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: Bob Hinden , 6man Mailing List , Brian Haberman 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, 11 May 2011 22:16:45 -0000 Hi Thomas, On Wed, 11 May 2011 17:12:55 -0400 Thomas Narten wrote: > Ole Troan writes: > > > That is, a CPE router with multiple LAN interfaces is not allowed to > > > advertise itself as a default router (when it loses internet > > > connectivity), when that is arguably a fine thing for it to do. > > > > > > I have to wonder whether RFC 6204 has gotten this wrong. It is very > > > CPE centric, assuming it is the only router on the home network. It > > > has conflated the notion of a router being fine as a default router > > > for the hosts attached to the same link (i.e., via RAs) and the the > > > more traditional router notion of default route. > > > > > > I.e., if the CPE router has multiple LAN interfaces, each with a ULA > > > (or other prefix) assigned to it, advertising itself as a default > > > router seems like a perfectly reasonable thing to do. > > > indeed, but unfortunately that causes IPv6 breakage. this is not at > > all CPE centric, from the CPE perspective advertising itself as a > > default router is obviously not an issue. the problem is host > > implementations that have a ULA address and a default route (but no > > connectivity to the IPv6 Internet). these hosts will choose IPv6 > > first when connecting to dual-stack destinations, this leads to > > multi-minute time outs. > > Let me be sure I understand. Which 3484 rule comes into play that has > an impact here? Is it: > > Rule 1: Avoid unusable destinations. > If DB is known to be unreachable or if Source(DB) is undefined, then > prefer DA. Similarly, if DA is known to be unreachable or if > Source(DA) is undefined, then prefer DB. > > I.e., if trying to reach a site, and the IPv6 address is "unreachable" > per above, choose the v4 address? (Sounds great in theory!). So the > CPE rule that says you MUST NOT advertise yourself as a default router > if you don't have real IPv6 connectivity is intended to result in all > destinations (other than local ones) showing up as "unreachable" when > the above rule happens? > > Is this the intention, or am I looking at the wrong scenario here? > I think what caught people a bit was a particular CPE which doesn't generate an ICMPv6 destination unreachable when the default IPv6 route disappeared or wasn't present (or didn't at the time - this caused my employer's customers a lot of grief when we started shipping IPv6 enabled by default in them). I tested this scenario with another CPE that did generate ICMPv6 destination reachables when the default route disappeared, and found that my end-node immediately reverted to using IPv4 when both AAAAs and As were available and the AAAA was offsite. However, as generating ICMPv6 dest unreachables is a SHOULD, not a MUST, and they can be rate limited, it seems to me that using RA RIOs to convey local IPv6 topology to end nodes is a more robust way of trying to ensure local IPv6 reachability across local subnets when the offsite default route disappears. So I agree with making supporting them a node requirement. Regards, Mark. From narten@us.ibm.com Thu May 12 06:09:53 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 43A6EE0710 for ; Thu, 12 May 2011 06:09:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEVA2ViWMgYe for ; Thu, 12 May 2011 06:09:50 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by ietfa.amsl.com (Postfix) with ESMTP id E9355E067A for ; Thu, 12 May 2011 06:09:49 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4CCnuVb012553 for ; Thu, 12 May 2011 08:49:56 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4CD9fct105638 for ; Thu, 12 May 2011 09:09:41 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4CD9f0V017739 for ; Thu, 12 May 2011 09:09:41 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-232-38.mts.ibm.com [9.65.232.38]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4CD9c66017601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 May 2011 09:09:39 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4CD9aGE006636; Thu, 12 May 2011 09:09:37 -0400 Message-Id: <201105121309.p4CD9aGE006636@cichlid.raleigh.ibm.com> To: Bob Hinden Subject: Re: Short 6MAN WG Last Call: In-reply-to: <4E9ECC9C-1648-4270-8736-C6ADD7379EA0@gmail.com> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <1C30F071-AD2E-4D55-9AAD-FCE7629BBC06@gmail.com> <201105100015.p4A0FwW3016108@cichlid.raleigh.ibm.com> <4E9ECC9C-1648-4270-8736-C6ADD7379EA0@gmail.com> Comments: In-reply-to Bob Hinden message dated "Mon, 09 May 2011 17:24:05 -0700." Date: Thu, 12 May 2011 09:09:36 -0400 From: Thomas Narten 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: Thu, 12 May 2011 13:09:53 -0000 > To put it another way, if we think there is a good use case for this > as Ole describes, we will be doing a service to the devices that > don't have their IPv6 code yet, to make it a SHOULD so they are > more likely to implement it. Here is some proposed text: 5.3. Default Router Preferences and More-Specific Routes - RFC 4191 "Default Router Preferences and More-Specific Routes" [RFC4191] provides support for nodes attached to multiple (different) networks each providing routers that advertise themselves as default routers via Router Advertisements. In some scenarios, one router may provide connectivity to destinations the other router does not, and choosing the "wrong" default router can result in reachability failures. In such cases, RFC4191 can help. Small Office/Home Office (SOHO) deployments supported by routers adhering to [RFC6204], use [RFC4191] to advertise routes to certain local destinations. Consequently, nodes that will be deployed in SOHO environments SHOULD implement [RFC4191]. Thoughts? Thomas From ichiroumakino@gmail.com Thu May 12 06:20: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 017F5E0791 for ; Thu, 12 May 2011 06:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Go9htxZsl1Ka for ; Thu, 12 May 2011 06:20:33 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAAAE078F for ; Thu, 12 May 2011 06:20:33 -0700 (PDT) Received: by eye13 with SMTP id 13so540912eye.31 for ; Thu, 12 May 2011 06:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=iXkMOG70jjZx+C/M7/hSCRmJucQCc8SmZNdqENEE+IU=; b=tJRbkYBBSQ9aix9kNofhV5/xaJpv6671JPOc+sC9lIMvlnZKOmY60KhJMjXUodkwV1 QuRyqIiPgTs8rPSr00Gvi5CqrzuK7EOoFYIxrs4KE67hP4GmflXxtl0ps+qqZoIMlCOH MhVDAiDmNOLpfDgtOVZ/Rh7sAzXjreg9E+9ug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=CaBq+NgEgewWuMqnovSWnGh7uyXxQ7+6CX/d10leRf8UDuleLWaXZibYOzfkN0dD1X 5MoBmzF9ULJF3Bf5K+NlKHAFPfDFo27fpDCw/pxU/gKilR/U4JfvpsGiw27z/xfm5MlN rgJXvsmxfuHUpeWuWV/doSZ/eKJMAQg7i5i+k= Received: by 10.213.4.10 with SMTP id 10mr140319ebp.102.1305206432109; Thu, 12 May 2011 06:20:32 -0700 (PDT) Received: from [192.168.1.138] (184.84-48-218.nextgentel.com [84.48.218.184]) by mx.google.com with ESMTPS id y3sm701248eeh.23.2011.05.12.06.20.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2011 06:20:31 -0700 (PDT) Sender: Ole Troan Subject: Re: Short 6MAN WG Last Call: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <201105121309.p4CD9aGE006636@cichlid.raleigh.ibm.com> Date: Thu, 12 May 2011 15:20:30 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3F936B0F-10BE-496C-BE8E-7A07BA836E8B@employees.org> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <1C30F071-AD2E-4D55-9AAD-FCE7629BBC06@gmail.com> <201105100015.p4A0FwW3016108@cichlid.raleigh.ibm.com> <4E9ECC9C-1648-4270-8736-C6ADD7379EA0@gmail.com> <201105121309.p4CD9aGE006636@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: 6man Mailing List , Brian Haberman , Bob Hinden 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, 12 May 2011 13:20:34 -0000 >> To put it another way, if we think there is a good use case for this >> as Ole describes, we will be doing a service to the devices that >> don't have their IPv6 code yet, to make it a SHOULD so they are >> more likely to implement it. > > Here is some proposed text: > > 5.3. Default Router Preferences and More-Specific Routes - RFC 4191 > > "Default Router Preferences and More-Specific Routes" [RFC4191] > provides support for nodes attached to multiple (different) networks > each providing routers that advertise themselves as default routers > via Router Advertisements. In some scenarios, one router may provide > connectivity to destinations the other router does not, and choosing > the "wrong" default router can result in reachability failures. In > such cases, RFC4191 can help. > > Small Office/Home Office (SOHO) deployments supported by routers > adhering to [RFC6204], use [RFC4191] to advertise routes to certain > local destinations. Consequently, nodes that will be deployed in > SOHO environments SHOULD implement [RFC4191]. > > Thoughts? I think that looks very good. cheers, Ole From narten@us.ibm.com Thu May 12 06:23:25 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 94903E07A2 for ; Thu, 12 May 2011 06:23:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8lp+0wKrfyp for ; Thu, 12 May 2011 06:23:25 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by ietfa.amsl.com (Postfix) with ESMTP id C225AE0791 for ; Thu, 12 May 2011 06:23:24 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4CD1f15010503 for ; Thu, 12 May 2011 09:01:41 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4CDNOwE093098 for ; Thu, 12 May 2011 09:23:24 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4CDNNFs001887 for ; Thu, 12 May 2011 09:23:23 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-232-38.mts.ibm.com [9.65.232.38]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4CDNME5001846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 May 2011 09:23:23 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4CDNKUM006703; Thu, 12 May 2011 09:23:21 -0400 Message-Id: <201105121323.p4CDNKUM006703@cichlid.raleigh.ibm.com> To: Ole Troan Subject: Re: Short 6MAN WG Last Call: In-reply-to: References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> Comments: In-reply-to Ole Troan message dated "Fri, 06 May 2011 20:54:26 +0200." Date: Thu, 12 May 2011 09:23:20 -0400 From: Thomas Narten Cc: Bob Hinden , 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: Thu, 12 May 2011 13:23:25 -0000 Ole, Getting back to some of your other points... Ole Troan writes: > >> * RFC2675: I would just remove that. > > > > The docuent currently says: > > > > IPv6 Jumbograms [RFC2675] MAY be supported. > > > > How about I replace that with: > > > > IPv6 Jumbograms [RFC2675] are an optional extension that allow > > the sending of IP datagrams larger than 65.535 bytes. IPv6 > > Jumbograms make use of IPv6 hop-by-hop options and are only > > suitable on paths in which every hop and link are capable of > > supporting Jumbograms (e.g., within a campus or datacenter). To > > date, few implementations exist and there is essentially no > > reported experience from usage. Consequently, IPv6 Jumbograms > > [RFC2675] remain optional at this time. > > > > (key change is "MAY" to just lower case "optional"). > I'm fine with that. > the reason I brought it up is because we have people (aka customers) > asking us for support for this. and it has so far in every case > been either because of mixing it up with jumbo frames, or not > understanding what it is. Understood. One of the goals of this version of the document is to make sure that there is real guidance, and not just "you SHOULD do this". If there is guidance, hopefully people will think a little bit more before asking vendors to implement something that does not appear to be needed in practice... > I disagree. the consequence is that hosts that not support DHCP, > will just not get service. that's pretty bad, and I think the > prudent approach would be to have SLAAC as a MUST and stateful as a > SHOULD. after all you have the following text that states: > "However, some environments may require the use of DHCP and may > not support the configuration of addresses via RAs." > that is a pretty severe interoperability problem. I'm happy that > 6106 is a SHOULD, but if you are looking for implementations for > that option you have to look very hard "at the present time". > basically I want the document to say that IETF has standardised two > mechanisms to configure hosts. one using ND and one using DHCP. as > they apply to different management models, nodes SHOULD implement > both. (and add suitable apologies to the world for having messed > this up badly. ;-)) I personally would support having DHCP be a SHOULD rather than a MAY. The justification in my mind is that if you want the network operator to have the choice of whether they want to use Stateless addrconf OR DHCP, they only have that choice of devices widely implement both. But that is not a new argument, and isn't any different today than it was ten years ago. And over the years, the WG has not always been particularly friendly towards DHCv6. It's only in the last few years that there has been an acceptance that DHCPv6 will actually get used on some deployments (by operator choice). However, I do not see evidence that the WG has changed its thinking and would now be willing to make implementation of DHCP a SHOULD. Unless this changes, I will leave the text as is. Thomas From rja.lists@gmail.com Thu May 12 07:55: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 E7607E072F for ; Thu, 12 May 2011 07:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 1BQTA4AiHR6G for ; Thu, 12 May 2011 07:55:48 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 595C1E0685 for ; Thu, 12 May 2011 07:55:48 -0700 (PDT) Received: by gxk19 with SMTP id 19so686989gxk.31 for ; Thu, 12 May 2011 07:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=xMVvetCWmZXVS728Cpj6k/3y/af/2uTtLo0oUSc8IfE=; b=T1CcIDebvHTs7+t8an1/Fa8Xdfx0d2BcT5irTxjztUNCFOQgC2R1bSNnfJEqfMHD4w oqwKSTreRgTZJ7vrY44RMCyHn93+VW1CoHfWSFKMNYp0K2QnIDxQVeXs460NuU+Uuyi1 kpLS2q8Sw5j8DcAbSXbTztIx9FCNm1nmiZkQk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=ucZSKNFDOtC/6BfuMLJJSzjBDMBPXrS+EAroiH7GtIpKZtwXmzjY2/tYvgxjqk5Yg9 IzVizN3/Hou6VYvRZFEKnkqa8dWlAuZArWb0e5Zdl7/gVoD5IQfxMSyHHymjvh5gFmgT m639Vxw6NNSm7YTPMNABxOJJgj29Ns+OqIXhY= Received: by 10.90.250.8 with SMTP id x8mr386711agh.164.1305212147433; Thu, 12 May 2011 07:55:47 -0700 (PDT) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id c38sm848287anc.18.2011.05.12.07.55.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2011 07:55:46 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Short 6MAN WG Last Call: Date: Thu, 12 May 2011 10:55:44 -0400 Message-Id: <4AAF4E5C-AAE3-43B0-A6A6-07246DF14B6F@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 12 May 2011 14:55:49 -0000 On Friday 6th May 2011, Ole Troan wrote in part: > basically I want the document to say that IETF has standardised > two mechanisms to configure hosts. one using ND and one using DHCP. > As they apply to different management models, nodes SHOULD implement both. On 12th May 2011, Thomas Narten responded in part: > I personally would support having DHCP be a SHOULD rather than a > MAY. The justification in my mind is that if you want the network > operator to have the choice of whether they want to use Stateless > addrconf OR DHCP, they only have that choice of devices widely > implement both. I share the views above. One wonders whether others also do. In some environments, IPv6 actually is NOT deployable unless/until DHCP for IPv6 is widely supported in IPv6 nodes. I agree with others here that cable modem deployments (e.g. DOCSIS) are one example where all node provisioning is handled via DHCP. A certain FTTH service that I myself use is a second example where DHCP is the node provisioning method. Numerous corporate, enterprise, educational, or government environments provide a 3rd example where DHCP for IPv6 is a pre-requisite for IPv6 deployment. Yours, Ran From randy@psg.com Thu May 12 10:55: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 0B4BDE077E for ; Thu, 12 May 2011 10:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 AGMz+gmX8QEl for ; Thu, 12 May 2011 10:55:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 9816CE0759 for ; Thu, 12 May 2011 10:55:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.home.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QKa5Q-00072r-Q0; Thu, 12 May 2011 17:54:09 +0000 Date: Thu, 12 May 2011 19:55:52 +0200 Message-ID: From: Randy Bush To: Thomas Narten Subject: Re: Short 6MAN WG Last Call: In-Reply-To: <201105121323.p4CDNKUM006703@cichlid.raleigh.ibm.com> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <201105121323.p4CDNKUM006703@cichlid.raleigh.ibm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: 6man Mailing List , Bob Hinden , Brian Haberman 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, 12 May 2011 17:55:36 -0000 > I personally would support having DHCP be a SHOULD rather than a > MAY. thank you randy From bob.hinden@gmail.com Thu May 12 13:39: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 D0D34E0780 for ; Thu, 12 May 2011 13:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 EDEVbhar2xgI for ; Thu, 12 May 2011 13:39:58 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5C3E073A for ; Thu, 12 May 2011 13:39:58 -0700 (PDT) Received: by pxi2 with SMTP id 2so1180795pxi.38 for ; Thu, 12 May 2011 13:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=R0l5CnPFattvKH33ogcEN0gJQFLAdTGfSYOq0EbVEic=; b=ogu+mW4/5Zdjeu5/Ws5MSAAFJuOfHWBD5mk0c5FaA5gMKpt+4BJyY4h9ujtg1JR+An 2su9Dj4HblE5XRODDUGZZ+UsiWgcEWej/+dHgdbABDgxnyi1zddogO0Anf+vneT5ADnF 8WHy/tmAw32pbySKLGw+TWNGRNqESoLxo/FJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=h8o5wDlscefQkp5+hTZ/zb89NiEapa8WfnEEG5FcEQvGizH24FC4Mp1THhzlgRMu7j ibCWnmcJLmPHr6McgK663kfA57a9wPf7MCIKwAPzBKRtzrB0E0B1OUv2VgBxsm9Vn1nI wufZGENfOkC1S+q95u950JordJHXDclaHzYDU= Received: by 10.68.20.233 with SMTP id q9mr930525pbe.299.1305232798095; Thu, 12 May 2011 13:39:58 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id q20sm877665pbt.72.2011.05.12.13.39.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2011 13:39:56 -0700 (PDT) Subject: Re: Short 6MAN WG Last Call: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4AAF4E5C-AAE3-43B0-A6A6-07246DF14B6F@gmail.com> Date: Thu, 12 May 2011 13:39:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10B824C0-28C1-42A0-85A8-BBBD1A96BC7D@gmail.com> References: <4AAF4E5C-AAE3-43B0-A6A6-07246DF14B6F@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org, Bob Hinden 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, 12 May 2011 20:39:58 -0000 Ran, On May 12, 2011, at 7:55 AM, RJ Atkinson wrote: > On Friday 6th May 2011, Ole Troan wrote in part: >> basically I want the document to say that IETF has standardised >> two mechanisms to configure hosts. one using ND and one using DHCP. >> As they apply to different management models, nodes SHOULD implement = both.=20 >=20 > On 12th May 2011, Thomas Narten responded in part: >> I personally would support having DHCP be a SHOULD rather than a >> MAY. The justification in my mind is that if you want the network >> operator to have the choice of whether they want to use Stateless >> addrconf OR DHCP, they only have that choice of devices widely >> implement both. >=20 > I share the views above. One wonders whether others also do. >=20 > In some environments, IPv6 actually is NOT deployable unless/until=20 > DHCP for IPv6 is widely supported in IPv6 nodes. =20 >=20 > I agree with others here that cable modem deployments (e.g. DOCSIS) > are one example where all node provisioning is handled via DHCP. =20 > A certain FTTH service that I myself use is a second example=20 > where DHCP is the node provisioning method. Numerous corporate, > enterprise, educational, or government environments provide a=20 > 3rd example where DHCP for IPv6 is a pre-requisite for IPv6 = deployment. While my personal view is that DHCPv6 won't be used for host = configuration in cable/DSL deployments (except for provisioning the = prefix to the home router), it appears that DHCPv6 is being widely = implemented in host OS's because it is needed some environments. There = are enough variations in deployment models that a host developer will = need to support both. =20 Based on this, I think a SHOULD is OK.=20 I do note that I had a conversation with a content provider who worked = closely with a mobile provider, and was surprised to learn that they = planned to use SLAACC for their servers because it made their job = easier. So I don't think we know what all people deploying IPv6 are = going to do in this area. =20 Bob From brian.e.carpenter@gmail.com Thu May 12 13:52:33 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 49326E07EC for ; Thu, 12 May 2011 13:52:33 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTIrWWeXQqaK for ; Thu, 12 May 2011 13:52:32 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6ADE067C for ; Thu, 12 May 2011 13:52:32 -0700 (PDT) Received: by fxm15 with SMTP id 15so1578933fxm.31 for ; Thu, 12 May 2011 13:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jtijrzSP+dxbq902Azdzov9Sf5K3IuAwsuJyAWFFAxg=; b=iQ8vqZJ4sRpqIa/gJjwLOqJKBpVPw95rryc+yzXCCgUUUqo5fYGGZz5NemfDoJCPu5 2h9MMm+GVNELYvGWFj2yEpBvKrdIe55zc+lM6bq8jBnkmvFs0LW08iE7ubLnbINhsY75 YqI/rqhJc2DNirTmEXngjIrO36APi6n7EghV8= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=CWdueE8oR0qO4P16Y0OCsX2/wUhyaSs+Kibd7jXGmoAdtnd+nUGnlMfOSy+9DVXzVN psQ5Oz/deSBrvzUgSUoX9Cis+2mU7eNZB12Sg1i2Y1oZgoYFowaHsVLYNjv+OPQVXTQ1 2l1G5U0dbJjhJOTmaIcDxtJ4SbMea28YkgH18= Received: by 10.223.57.5 with SMTP id a5mr785827fah.90.1305233551637; Thu, 12 May 2011 13:52:31 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n7sm603752fam.35.2011.05.12.13.52.27 (version=SSLv3 cipher=OTHER); Thu, 12 May 2011 13:52:30 -0700 (PDT) Message-ID: <4DCC4885.1030701@gmail.com> Date: Fri, 13 May 2011 08:52:21 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: Short 6MAN WG Last Call: References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <201105121323.p4CDNKUM006703@cichlid.raleigh.ibm.com> In-Reply-To: <201105121323.p4CDNKUM006703@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man Mailing List , Bob Hinden , Brian Haberman 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, 12 May 2011 20:52:33 -0000 On 2011-05-13 01:23, Thomas Narten wrote: ... > I personally would support having DHCP be a SHOULD rather than a > MAY. The justification in my mind is that if you want the network > operator to have the choice of whether they want to use Stateless > addrconf OR DHCP, they only have that choice of devices widely > implement both. +1 > But that is not a new argument, and isn't any different today than it > was ten years ago. I think it is, and it certainly is if you make that "fifteen years ago" when DHCP(v4) was operationally young and the IPv6 design did not assume the existence of DHCPv6. There will, I'm sure, be many scenarios in the future where SLAAC is just fine; but it's time for DHCPv6 to be a first-class citizen. Brian From ipng@69706e6720323030352d30312d31340a.nosense.org Thu May 12 14:55: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 E9760E07D6 for ; Thu, 12 May 2011 14:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 PHisws1COBnB for ; Thu, 12 May 2011 14:55:08 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 23AB0E066E for ; Thu, 12 May 2011 14:55:08 -0700 (PDT) Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QKdqR-0007pe-QF; Fri, 13 May 2011 07:24:55 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 480D53B338; Fri, 13 May 2011 07:24:55 +0930 (CST) Date: Fri, 13 May 2011 07:24:55 +0930 From: Mark Smith To: Ole Troan Subject: Re: Short 6MAN WG Last Call: Message-ID: <20110513072455.722b9467@opy.nosense.org> In-Reply-To: <3F936B0F-10BE-496C-BE8E-7A07BA836E8B@employees.org> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <1C30F071-AD2E-4D55-9AAD-FCE7629BBC06@gmail.com> <201105100015.p4A0FwW3016108@cichlid.raleigh.ibm.com> <4E9ECC9C-1648-4270-8736-C6ADD7379EA0@gmail.com> <201105121309.p4CD9aGE006636@cichlid.raleigh.ibm.com> <3F936B0F-10BE-496C-BE8E-7A07BA836E8B@employees.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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: Thomas Narten , Bob Hinden , 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: Thu, 12 May 2011 21:55:09 -0000 On Thu, 12 May 2011 15:20:30 +0200 Ole Troan wrote: > >> To put it another way, if we think there is a good use case for this > >> as Ole describes, we will be doing a service to the devices that > >> don't have their IPv6 code yet, to make it a SHOULD so they are > >> more likely to implement it. > > > > Here is some proposed text: > > > > 5.3. Default Router Preferences and More-Specific Routes - RFC 4191 > > > > "Default Router Preferences and More-Specific Routes" [RFC4191] > > provides support for nodes attached to multiple (different) networks > > each providing routers that advertise themselves as default routers > > via Router Advertisements. In some scenarios, one router may provide > > connectivity to destinations the other router does not, and choosing > > the "wrong" default router can result in reachability failures. In > > such cases, RFC4191 can help. > > > > Small Office/Home Office (SOHO) deployments supported by routers > > adhering to [RFC6204], use [RFC4191] to advertise routes to certain > > local destinations. Consequently, nodes that will be deployed in > > SOHO environments SHOULD implement [RFC4191]. > > > > Thoughts? > > I think that looks very good. > +1 > cheers, > Ole > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From ipng@69706e6720323030352d30312d31340a.nosense.org Thu May 12 15:07: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 38D95E07FC for ; Thu, 12 May 2011 15:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 Bd-zb9BNVfnF for ; Thu, 12 May 2011 15:07:34 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0FFE066E for ; Thu, 12 May 2011 15:07:34 -0700 (PDT) Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QKe2c-0008GG-KG; Fri, 13 May 2011 07:37:30 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 2D70C3B338; Fri, 13 May 2011 07:37:30 +0930 (CST) Date: Fri, 13 May 2011 07:37:29 +0930 From: Mark Smith To: Thomas Narten Subject: Re: Short 6MAN WG Last Call: Message-ID: <20110513073729.52a39f70@opy.nosense.org> In-Reply-To: <201105121323.p4CDNKUM006703@cichlid.raleigh.ibm.com> References: <05DD243A-277C-4777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.raleigh.ibm.com> <201105121323.p4CDNKUM006703@cichlid.raleigh.ibm.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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: 6man Mailing List , Bob Hinden , Brian Haberman 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, 12 May 2011 22:07:35 -0000 Hi Thomas, On Thu, 12 May 2011 09:23:20 -0400 Thomas Narten wrote: > Ole, > > Getting back to some of your other points... > > Ole Troan writes: > > >> * RFC2675: I would just remove that. > > > > > However, I do not see evidence that the WG has changed its thinking > and would now be willing to make implementation of DHCP a SHOULD. > I think it would be reasonable to make DHCP a SHOULD, however I've thought that one of the reasons SLAAC exists is to provide simpler and lighter weight address configuration method for resource constrained end-nodes such as embedded ones. So perhaps it could be worth mentioning that an example of an exception to the SHOULD would be those types of end-nodes. Regards, Mark. From albert.e.manfredi@boeing.com Thu May 12 15:22:28 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 9DFE4E066E for ; Thu, 12 May 2011 15:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dDQL8Hz3QI6E for ; Thu, 12 May 2011 15:22:28 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id A38C7E0680 for ; Thu, 12 May 2011 15:22:26 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4CMM9Qm028893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 May 2011 15:22:09 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p4CMM9Vc011372; Thu, 12 May 2011 15:22:09 -0700 (PDT) Received: from XCH-MWHT-03.mw.nos.boeing.com (xch-mwht-03.mw.nos.boeing.com [134.57.119.161]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4CMM85V011352 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 12 May 2011 15:22:08 -0700 (PDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-03.mw.nos.boeing.com ([134.57.119.161]) with mapi; Thu, 12 May 2011 17:22:08 -0500 From: "Manfredi, Albert E" To: Mark Smith Date: Thu, 12 May 2011 17:22:05 -0500 Subject: RE: Short 6MAN WG Last Call: Thread-Topic: Short 6MAN WG Last Call: Thread-Index: AcwQ8Q14cGxc7Yh6S16LVc7k/mDtMQAASGsg Message-ID: References: <05DD243A-277C-4 777-91D0-CB9E609E733A@employees.org><201105061748.p46HmJu8015684@cichlid.ra leigh.ibm.com><201105121323.p4CDNKUM006703@cichlid.raleigh.ibm.com> <20110513073729.52a39f70@opy.nosense.org> In-Reply-To: <20110513073729.52a39f70@opy.nosense.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Thu, 12 May 2011 22:22:28 -0000 Mark Smith wrote: > I think it would be reasonable to make DHCP a SHOULD, however > I've thought that one of the reasons SLAAC exists is to provide > simpler and lighter weight address configuration method for resource > constrained end-nodes such as embedded ones. So perhaps it could be > worth mentioning that an example of an exception to the SHOULD would be > those types of end-nodes. More generally, I'd say SLAAC exists because with IPv6 it's possible to ass= ign globally unique IP addresses to hosts, without risk of collisions, with= out having to have the network specify all of the 128 bits. But in situations where the address provided to a host must be completely p= redictable, SLAAC won't work. I don't think that resource-constrained need to be a significant criterion? Bert From dougb@dougbarton.us Thu May 12 15:40: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 5B141E07DA for ; Thu, 12 May 2011 15:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.766 X-Spam-Level: X-Spam-Status: No, score=-3.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 2W4B7W3-MoFA for ; Thu, 12 May 2011 15:40:18 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 740D2E0780 for ; Thu, 12 May 2011 15:40:18 -0700 (PDT) Received: (qmail 20939 invoked by uid 399); 12 May 2011 22:40:14 -0000 Received: from unknown (HELO ?65.241.43.5?) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 12 May 2011 22:40:14 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DCC61CD.10005@dougbarton.us> Date: Thu, 12 May 2011 15:40:13 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Manfredi, Albert E" Subject: Re: Short 6MAN WG Last Call: References: <05DD243A-277C-4 777-91D0-CB9E609E733A@employees.org><201105061748.p46HmJu8015684@cichlid.ra leigh.ibm.com><201105121323.p4CDNKUM006703@cichlid.raleigh.ibm.com> <20110513073729.52a39f70@opy.nosense.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Thu, 12 May 2011 22:40:19 -0000 On 5/12/2011 3:22 PM, Manfredi, Albert E wrote: > Mark Smith wrote: > >> I think it would be reasonable to make DHCP a SHOULD, however >> I've thought that one of the reasons SLAAC exists is to provide >> simpler and lighter weight address configuration method for resource >> constrained end-nodes such as embedded ones. So perhaps it could be >> worth mentioning that an example of an exception to the SHOULD would be >> those types of end-nodes. > > More generally, I'd say SLAAC exists because with IPv6 it's possible to assign globally unique IP addresses to hosts, without risk of collisions, without having to have the network specify all of the 128 bits. > > But in situations where the address provided to a host must be completely predictable, SLAAC won't work. > > I don't think that resource-constrained need to be a significant criterion? Rather than trying to enumerate all the reasons that it might be one or the other, how about language to the effect of: If building a special-purpose device for use on a network where only RA/SLAAC is allowed then implementors MAY omit DHCPv6 support. Otherwise DHCPv6 SHOULD be provided. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From internet-drafts@ietf.org Thu May 12 17:16:53 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 730A3E06D9; Thu, 12 May 2011 17:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 uj+ojen6j2r1; Thu, 12 May 2011 17:16:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAFBE065A; Thu, 12 May 2011 17:16:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-flow-3697bis-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110513001652.13582.31825.idtracker@ietfa.amsl.com> Date: Thu, 12 May 2011 17:16:52 -0700 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, 13 May 2011 00:16:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : IPv6 Flow Label Specification Author(s) : Shane Amante Brian Carpenter Sheng Jiang Jarno Rajahalme Filename : draft-ietf-6man-flow-3697bis-04.txt Pages : 15 Date : 2011-05-12 This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-04.txt From internet-drafts@ietf.org Thu May 12 17:17:33 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 ADC32130014; Thu, 12 May 2011 17:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1vyUCqm036KU; Thu, 12 May 2011 17:17:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115C4E065A; Thu, 12 May 2011 17:17:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-flow-update-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110513001722.13659.12659.idtracker@ietfa.amsl.com> Date: Thu, 12 May 2011 17:17:22 -0700 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, 13 May 2011 00:17:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Rationale for update to the IPv6 flow label specification Author(s) : Shane Amante Brian Carpenter Sheng Jiang Filename : draft-ietf-6man-flow-update-06.txt Pages : 13 Date : 2011-05-12 Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it, and to introduce some additional flexibility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-flow-update-06.txt From brian.e.carpenter@gmail.com Thu May 12 17:26: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 6BA2CE06C4 for ; Thu, 12 May 2011 17:26:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUAiDKsWcWOW for ; Thu, 12 May 2011 17:26:44 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 95E08E065A for ; Thu, 12 May 2011 17:26:44 -0700 (PDT) Received: by fxm15 with SMTP id 15so1674885fxm.31 for ; Thu, 12 May 2011 17:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2+D4JyiA2WswQM/mfE3vWLffkGe6z30Gr+Rn9xqGWL0=; b=CCCqHIS7r/lgzOr1jmTbixWJhZ1yHSUmZjJ5dLf5WC4HBiViJaIeinZMgbnVGXC+l1 16QRItGx8l3v9uNK8fysklUFjCsO+RZ+jTL6KpmI1M4LGvizqXtmD52GjCXQ7r2hqZmH 9iiC9BSgdgOl40LPDJNorBxMpvX+7renY6aFg= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=pjPiZcnPto9szziKMb3t4VUt/JQ9/ZISpLxd3tpiXkz6h/8eFrRTCYxKty8rx2ZX2P AoKrBgHgekT10Q82Xx3TRmKR+UQcvFHVM9IV5sya65NEpJ5xk/I23bcJCVM1E4Eb5HQD /shd1v6MFPqMsen0tG+w6AqHRm2wTxCBf2RdQ= Received: by 10.223.110.21 with SMTP id l21mr987975fap.70.1305246403663; Thu, 12 May 2011 17:26:43 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id j18sm645129faa.42.2011.05.12.17.26.40 (version=SSLv3 cipher=OTHER); Thu, 12 May 2011 17:26:42 -0700 (PDT) Message-ID: <4DCC7ABD.2060505@gmail.com> Date: Fri, 13 May 2011 12:26:37 +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: Flow label drafts updated again References: <4D77DBD8.4090800@innovationslab.net> <4D792360.5@gmail.com> <4D7A2995.9090204@innovationslab.net> <5D36713D8A4E7348A7E10DF7437A4B927FCAE2@SZXEML504-MBX.china.huawei.com> <4DB8C07B.8060004@gmail.com> <1B02010E-CE2C-45D7-938E-6FFED7721752@castlepoint.net> <4DBB1997.8030709@gmail.com> <4DBB2618.3070705@gmail.com> <3769FB5A-DACF-48B0-BB43-06D0669D6D1E@castlepoint.net> <4DBE1718.2080104@gmail.com> In-Reply-To: <4DBE1718.2080104@gmail.com> Content-Type: text/plain; charset=UTF-8 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: Fri, 13 May 2011 00:26:45 -0000 Hi, The RFC3697bis draft has been updated again, principally to resolve the remaining points raised by Thomas Narten and the point raised by Ran Atkinson. The rationale draft (draft-carpenter-6man-flow-update) has been updated to keep it in step (for example, some additional references for firewall issues have been added, and it explains why 3697bis no longer uses the word "immutable".) The authors believe that all significant issues have been dealt with. The summary of changes in 3697bis is: o Suggested a specific hash algorithm to generate a flow label. o Removed reference to stateful domain. o Added text about covert channel and tuned text about firewall behavior; removed the confusing word "immutable". o Added that Section 6 of RFC 2460 is replaced. o Editorial fixes. There were no open issues on the ECMP-LAG draft, so that has not been updated. You can find all three drafts at: https://datatracker.ietf.org/doc/search/?name=draft-ietf-6man-flow&activeDrafts=on Regards Brian + co-authors From narten@us.ibm.com Fri May 13 06:39:16 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 5548EE06D7 for ; Fri, 13 May 2011 06:39:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXF9HHKEFnOp for ; Fri, 13 May 2011 06:39:15 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id CA5CDE069B for ; Fri, 13 May 2011 06:39:15 -0700 (PDT) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4DDRblj004058 for ; Fri, 13 May 2011 07:27:37 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4DDbhFr215660 for ; Fri, 13 May 2011 07:37:44 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4D7bf9g006531 for ; Fri, 13 May 2011 01:37:41 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-244-19.mts.ibm.com [9.65.244.19]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4D7beII006423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 May 2011 01:37:40 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4DDbdao009901 for ; Fri, 13 May 2011 09:37:39 -0400 Message-Id: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> To: ipv6@ietf.org Subject: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Date: Fri, 13 May 2011 09:37:39 -0400 From: Thomas Narten 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, 13 May 2011 13:39:16 -0000 Per a previous thread, there are indications that the WG may now be willing to recommend that DHCPv6 be a SHOULD for all hosts. This is based on the following rationale: Thomas Narten writes: > I personally would support having DHCP be a SHOULD rather than a > MAY. The justification in my mind is that if you want the network > operator to have the choice of whether they want to use Stateless > addrconf OR DHCP, they only have that choice of devices widely > implement both. This was supported by some others, particularly now that it is clear there are more implementations of DHCPv6, e.g.: Bob Hinden writes: > While my personal view is that DHCPv6 won't be used for host > configuration in cable/DSL deployments (except for provisioning the > prefix to the home router), it appears that DHCPv6 is being widely > implemented in host OS's because it is needed some environments. > There are enough variations in deployment models that a host > developer will need to support both. > Based on this, I think a SHOULD is OK. Let me propose the following change be made to the node requirements document: OLD/Current: DHCP can be used to obtain and configure addresses. In general, a network may provide for the configuration of addresses through Router Advertisements, DHCP or both. At the present time, the configuration of addresses via stateless autoconfiguration is more widely implemented in hosts than address configuration via DHCP. However, some environments may require the use of DHCP and may not support the configuration of addresses via RAs. Implementations should be aware of what operating environment their devices will be deployed. Hosts MAY implement address configuration via DHCP. New: DHCPv6 can be used to obtain and configure addresses. In general, a network may provide for the configuration of addresses through Router Advertisements, DHCPv6 or both. Some operators have indicated that they do not intend to support stateless address autoconfiguration on their networks and will require all address assignments be made through DHCPv6. On such networks, devices that support only stateless address autoconfiguration will be unable to automatically configure addresses. Consequently all hosts SHOULD implement address configuration via DHCP. Is this acceptable? Please respond yes or no. Given the WG's previous hesitation to having DHCPv6 be a SHOULD, it is important that we get a clear indication of whether or not the WG supports this change. Thomas From rdroms.ietf@gmail.com Fri May 13 06:45: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 59C35E06D7 for ; Fri, 13 May 2011 06:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 nZtj8b3I6fT6 for ; Fri, 13 May 2011 06:45:42 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB821E069B for ; Fri, 13 May 2011 06:45:42 -0700 (PDT) Received: by gyf3 with SMTP id 3so1107093gyf.31 for ; Fri, 13 May 2011 06:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=dHKVP3yHxFRmIckzVRslIu9CDukF3fNiezPicosQKc4=; b=crjQuWv4MHd5to5Er8RTDfss/QP530rmSovj66afLK3ll11UO8uIkovp3kgrA3Ea30 NhZZk2G/exCmhjdoQfdRgvyBn3BKJXXwnYjIFqsm2xlfofY+gX6xCCcwGlTIZ5nXMGDj VDiRw0miwUkbmYr4srzBVuLlO4WIHDNCx28c0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=DL9gV+PQ8tj/ggZOzVAfuKY+zmqpg2/HRyJg4ljAuwt96GBBILQifatkR/MdVPitTy WhHe3r7MpcZR4z3AH7OA/K6fJR9xkBxYrClGXnG/8T8oLsZuPkWJi/+ou88gtTUpGWHo BL5rbBykH/Dk+ohNayFJRzIB9PHvvZn2i8pQQ= Received: by 10.147.127.4 with SMTP id e4mr1232699yan.17.1305294342113; Fri, 13 May 2011 06:45:42 -0700 (PDT) Received: from bxb-rdroms-8712.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id s11sm1644967anm.40.2011.05.13.06.45.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2011 06:45:40 -0700 (PDT) Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> Date: Fri, 13 May 2011 09:45:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8AC0FCE1-E53F-4E43-9C55-025136553D88@gmail.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1082) Cc: ipv6@ietf.org, Ralph Droms 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, 13 May 2011 13:45:43 -0000 Thomas... On May 13, 2011, at 9:37 AM 5/13/11, Thomas Narten wrote: > Per a previous thread, there are indications that the WG may now be > willing to recommend that DHCPv6 be a SHOULD for all hosts. This is > based on the following rationale: >=20 > Thomas Narten writes: >=20 >> I personally would support having DHCP be a SHOULD rather than a >> MAY. The justification in my mind is that if you want the network >> operator to have the choice of whether they want to use Stateless >> addrconf OR DHCP, they only have that choice of devices widely >> implement both. >=20 > This was supported by some others, particularly now that it is clear > there are more implementations of DHCPv6, e.g.: >=20 > Bob Hinden writes: >=20 >> While my personal view is that DHCPv6 won't be used for host >> configuration in cable/DSL deployments (except for provisioning the >> prefix to the home router), it appears that DHCPv6 is being widely >> implemented in host OS's because it is needed some environments. >> There are enough variations in deployment models that a host >> developer will need to support both. >=20 >> Based on this, I think a SHOULD is OK.=20 >=20 > Let me propose the following change be made to the node requirements > document: >=20 > OLD/Current: >=20 > DHCP can be used to obtain and configure addresses. In general, a > network may provide for the configuration of addresses through = Router > Advertisements, DHCP or both. At the present time, the = configuration > of addresses via stateless autoconfiguration is more widely > implemented in hosts than address configuration via DHCP. However, > some environments may require the use of DHCP and may not support = the > configuration of addresses via RAs. Implementations should be aware > of what operating environment their devices will be deployed. Hosts > MAY implement address configuration via DHCP. >=20 > New: >=20 > DHCPv6 can be used to obtain and > configure addresses. In general, a network may provide for the > configuration of addresses through Router Advertisements, > DHCPv6 or both. Some operators have indicated that they do > not intend to support stateless address autoconfiguration on > their networks and will require all address assignments be > made through DHCPv6. On such networks, devices that support > only stateless address autoconfiguration will be unable to > automatically configure addresses. Consequently all hosts > SHOULD implement address configuration via DHCP. >=20 >=20 > Is this acceptable? Looks fine and appropriate to me, with one nit: s/DHCP/DHCPv6/ in the = last line. - Ralph > Please respond yes or no. Given the WG's previous hesitation to having > DHCPv6 be a SHOULD, it is important that we get a clear indication of > whether or not the WG supports this change. >=20 > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From tjc@ecs.soton.ac.uk Fri May 13 07:29:21 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 7EC55E0737 for ; Fri, 13 May 2011 07:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 iXYWhMOdEUNw for ; Fri, 13 May 2011 07:29:20 -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 34532E069B for ; Fri, 13 May 2011 07:29:19 -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 p4DETG78013145 for ; Fri, 13 May 2011 15:29:16 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p4DETG78013145 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1305296957; bh=JXHvLRMHavvxqEDs8alENu7aU1c=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=xN1Bokpcb9YdADYmSodiUVW3+dk1M9+eg4E4hEk7Tfu6P8QW/vUtYZjdf6XGxtDlE EtpLKQDbenroN26I8XJSAstd+Od+4OD0bigCT6tlWcsLm7Nav/l7nzaZgiOBFfApjO XDd2hy9UklLY8GdWXEyFULq5BWliFXd7zDO+6XLk= 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 n4CFYG003561767317 ret-id none; Fri, 13 May 2011 15:29:16 +0100 Received: from dhcp-152-78-94-92.ecs.soton.ac.uk (dhcp-152-78-94-92.ecs.soton.ac.uk [152.78.94.92]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p4DET9Df008996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 13 May 2011 15:29:10 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: Tim Chown In-Reply-To: <8AC0FCE1-E53F-4E43-9C55-025136553D88@gmail.com> Date: Fri, 13 May 2011 15:29:09 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <8AC0FCE1-E53F-4E43-9C55-025136553D88@gmail.com> <995E5831-C06D-42B2-8955-80BB1372DD09@ecs.soton.ac.uk> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n4CFYG003561767300; tid=n4CFYG003561767317; 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: p4DETG78013145 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, 13 May 2011 14:29:21 -0000 On 13 May 2011, at 14:45, Ralph Droms wrote: >>=20 >> New: >>=20 >> DHCPv6 can be used to obtain and >> configure addresses. In general, a network may provide for the >> configuration of addresses through Router Advertisements, >> DHCPv6 or both. Some operators have indicated that they do >> not intend to support stateless address autoconfiguration on >> their networks and will require all address assignments be >> made through DHCPv6. On such networks, devices that support >> only stateless address autoconfiguration will be unable to >> automatically configure addresses. Consequently all hosts >> SHOULD implement address configuration via DHCP. >>=20 >>=20 >> Is this acceptable? >=20 > Looks fine and appropriate to me, with one nit: s/DHCP/DHCPv6/ in the = last line. Looks good. =20 Personally I would probably say 'support' rather than 'implement' in the = last sentence, as per the first sentence of 5.9.2 where we say "Hosts = MUST support IPv6 Stateless Address Autoconfiguration", but either is = OK. Tim= From cb.list6@gmail.com Fri May 13 07:35: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 79D38E074D for ; Fri, 13 May 2011 07:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 3fjJ9Obbkf7G for ; Fri, 13 May 2011 07:35:45 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 88E9EE06A6 for ; Fri, 13 May 2011 07:35:44 -0700 (PDT) Received: by eye13 with SMTP id 13so919180eye.31 for ; Fri, 13 May 2011 07:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eq1eaiLL6XkGUAjVuCj0ckt6bXT1hDePnB0cuTOpXJo=; b=IeIr4+BHw4/yjJQr5RPv0OpmwpPP1eVbm5dkqh9v6tQXRG1pnaUSdQX4TlD0I7mMPm vgxa48lurq8lifUG2ysOvWDKXsDsBhSHC4J+5kRJwjdibOAqKkyaM47dE9E3/5CwcMLk aeIvxcVnD5LKoZLaVajKC6iKfjlVQBLA0ncEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Q0Y9mLES738gJOwTrqsIyYsu13k/SoytMVH9BYOwJ5qwfggE9SoWhzLjiRQkMXUYNM OMdZvZc1uil4zex5vzdtYP45nUJhsHjl6+e1fEtWyYWcDvV2XSvUquOoWeqMk6eXW1B2 2XTjpxnmFHZjzJ9v2HCQh1PjEPjSucb0h1Gqg= MIME-Version: 1.0 Received: by 10.14.127.76 with SMTP id c52mr690614eei.57.1305297343357; Fri, 13 May 2011 07:35:43 -0700 (PDT) Received: by 10.14.37.143 with HTTP; Fri, 13 May 2011 07:35:42 -0700 (PDT) Received: by 10.14.37.143 with HTTP; Fri, 13 May 2011 07:35:42 -0700 (PDT) In-Reply-To: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> Date: Fri, 13 May 2011 07:35:42 -0700 Message-ID: Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: Cameron Byrne To: Thomas Narten Content-Type: multipart/alternative; boundary=90e6ba5bb8f37a263a04a3293843 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, 13 May 2011 14:35:46 -0000 --90e6ba5bb8f37a263a04a3293843 Content-Type: text/plain; charset=ISO-8859-1 On May 13, 2011 6:39 AM, "Thomas Narten" wrote: > > Per a previous thread, there are indications that the WG may now be > willing to recommend that DHCPv6 be a SHOULD for all hosts. This is > based on the following rationale: > > Thomas Narten writes: > > > I personally would support having DHCP be a SHOULD rather than a > > MAY. The justification in my mind is that if you want the network > > operator to have the choice of whether they want to use Stateless > > addrconf OR DHCP, they only have that choice of devices widely > > implement both. > > This was supported by some others, particularly now that it is clear > there are more implementations of DHCPv6, e.g.: > > Bob Hinden writes: > > > While my personal view is that DHCPv6 won't be used for host > > configuration in cable/DSL deployments (except for provisioning the > > prefix to the home router), it appears that DHCPv6 is being widely > > implemented in host OS's because it is needed some environments. > > There are enough variations in deployment models that a host > > developer will need to support both. > > > Based on this, I think a SHOULD is OK. > > Let me propose the following change be made to the node requirements > document: > > OLD/Current: > > DHCP can be used to obtain and configure addresses. In general, a > network may provide for the configuration of addresses through Router > Advertisements, DHCP or both. At the present time, the configuration > of addresses via stateless autoconfiguration is more widely > implemented in hosts than address configuration via DHCP. However, > some environments may require the use of DHCP and may not support the > configuration of addresses via RAs. Implementations should be aware > of what operating environment their devices will be deployed. Hosts > MAY implement address configuration via DHCP. > > New: > > DHCPv6 can be used to obtain and > configure addresses. In general, a network may provide for the > configuration of addresses through Router Advertisements, > DHCPv6 or both. Some operators have indicated that they do > not intend to support stateless address autoconfiguration on > their networks and will require all address assignments be > made through DHCPv6. On such networks, devices that support > only stateless address autoconfiguration will be unable to > automatically configure addresses. Consequently all hosts > SHOULD implement address configuration via DHCP. > > > Is this acceptable? > > Please respond yes or no. Given the WG's previous hesitation to having > DHCPv6 be a SHOULD, it is important that we get a clear indication of > whether or not the WG supports this change. > Yes. I support the new text. Cb > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --90e6ba5bb8f37a263a04a3293843 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On May 13, 2011 6:39 AM, "Thomas Narten" <narten@us.ibm.com> wrote:
>
> Per a previous thread, there are indications that the WG may now be > willing to recommend that DHCPv6 be a SHOULD for all hosts. This is > based on the following rationale:
>
> Thomas Narten <narten@us.ibm.c= om> writes:
>
> > I personally would support having DHCP be a SHOULD rather than a<= br> > > MAY. The justification in my mind is that if you want the network=
> > operator to have the choice of whether they want to use =A0Statel= ess
> > addrconf OR DHCP, they only have that choice of devices widely > > implement both.
>
> This was supported by some others, particularly now that it is clear > there are more implementations of DHCPv6, e.g.:
>
> Bob Hinden <bob.hinden@gmai= l.com> writes:
>
> > While my personal view is that DHCPv6 won't be used for host<= br> > > configuration in cable/DSL deployments (except for provisioning t= he
> > prefix to the home router), it appears that DHCPv6 is being widel= y
> > implemented in host OS's because it is needed some environmen= ts.
> > There are enough variations in deployment models that a host
> > developer will need to support both.
>
> > Based on this, I think a SHOULD is OK.
>
> Let me propose the following change be made to the node requirements > document:
>
> OLD/Current:
>
> =A0 DHCP can be used to obtain and configure addresses. =A0In general,= a
> =A0 network may provide for the configuration of addresses through Rou= ter
> =A0 Advertisements, DHCP or both. =A0At the present time, the configur= ation
> =A0 of addresses via stateless autoconfiguration is more widely
> =A0 implemented in hosts than address configuration via DHCP. =A0Howev= er,
> =A0 some environments may require the use of DHCP and may not support = the
> =A0 configuration of addresses via RAs. =A0Implementations should be a= ware
> =A0 of what operating environment their devices will be deployed. =A0H= osts
> =A0 MAY implement address configuration via DHCP.
>
> New:
>
> =A0 =A0 =A0 =A0<t> DHCPv6 <xref target=3D'RFC3315' /&= gt; can be used to obtain and
> =A0 =A0 =A0 =A0configure addresses. In general, a network may provide = for the
> =A0 =A0 =A0 =A0configuration of addresses through Router Advertisement= s,
> =A0 =A0 =A0 =A0DHCPv6 or both. =A0Some operators have indicated that t= hey do
> =A0 =A0 =A0 =A0not intend to support stateless address autoconfigurati= on on
> =A0 =A0 =A0 =A0their networks and will require all address assignments= be
> =A0 =A0 =A0 =A0made through DHCPv6. On such networks, devices that sup= port
> =A0 =A0 =A0 =A0only stateless address autoconfiguration will be unable= to
> =A0 =A0 =A0 =A0automatically configure addresses. Consequently all hos= ts
> =A0 =A0 =A0 =A0SHOULD implement address configuration via DHCP.</t&= gt;
>
>
> Is this acceptable?
>
> Please respond yes or no. Given the WG's previous hesitation to ha= ving
> DHCPv6 be a SHOULD, it is important that we get a clear indication of<= br> > whether or not the WG supports this change.
>

Yes. I support the new text.

Cb

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

--90e6ba5bb8f37a263a04a3293843-- From scott.brim@gmail.com Fri May 13 08:16: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 F281BE06C9 for ; Fri, 13 May 2011 08:16:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-cyTruevU4M for ; Fri, 13 May 2011 08:16:16 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A544E0670 for ; Fri, 13 May 2011 08:16:16 -0700 (PDT) Received: by iwn39 with SMTP id 39so3011151iwn.31 for ; Fri, 13 May 2011 08:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fEOsTpEFA2B00349tygFi+WKi3rXBs0P+eEJcvGsg0s=; b=aaG+yuZaNeluyX1uDUmpjEyEjXNlR5rsmu5HG1S/A3qdl9L0/H9553CCuownpCLHnL d1SUk391v0VhQr24LQ17819N2fRTSunXclwDCilQXOoQKt5gPH6C29Y4D+zogqTNvQBb TdqNEzz9ZPy9YQwlyuAhsaJsQh1ZnmRjNbd+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=WgpELsj9E9rAMZ+UgXnMid9ykaczBtCMW8njrixfKSO2eABJisuYmZbPwzy+pufFZO 1ohoZL6S/ll6aQZDF8P5rM3Z+4kv76QMFp3Ztsh+7LKq/7ji5ch8orVdPjsv4BzqtO+s 25KQY5J4NlWQ0aetIGf5BLawhriVGZVPNE9k8= Received: by 10.42.230.138 with SMTP id jm10mr1832781icb.451.1305299776072; Fri, 13 May 2011 08:16:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.30.205 with HTTP; Fri, 13 May 2011 08:15:55 -0700 (PDT) In-Reply-To: <8AC0FCE1-E53F-4E43-9C55-025136553D88@gmail.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <8AC0FCE1-E53F-4E43-9C55-025136553D88@gmail.com> From: Scott Brim Date: Fri, 13 May 2011 11:15:55 -0400 Message-ID: Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Cc: Thomas Narten , 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, 13 May 2011 15:16:17 -0000 On Fri, May 13, 2011 at 09:45, Ralph Droms wrote: > Looks fine and appropriate to me, with one nit: s/DHCP/DHCPv6/ in the last line. +1 From Fred.L.Templin@boeing.com Fri May 13 08:42: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 8E10DE07A0 for ; Fri, 13 May 2011 08:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 8lQk5OfIruMc for ; Fri, 13 May 2011 08:42:08 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 06009E0792 for ; Fri, 13 May 2011 08:42:07 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4DFg4m3017552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 May 2011 10:42:05 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p4DFg4np017894; Fri, 13 May 2011 08:42:04 -0700 (PDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4DFg3Iw017889 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 13 May 2011 08:42:04 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Fri, 13 May 2011 08:42:03 -0700 From: "Templin, Fred L" To: Thomas Narten , "ipv6@ietf.org" Date: Fri, 13 May 2011 08:42:01 -0700 Subject: RE: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AcwRczEPXGBVt65vSOWcpLl7lCRhkAAEQGlg Message-ID: References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> In-Reply-To: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Fri, 13 May 2011 15:42:08 -0000 > Please respond yes or no. Given the WG's previous hesitation to having > DHCPv6 be a SHOULD, it is important that we get a clear indication of > whether or not the WG supports this change. Should be a SHOULD. Fred > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = From bob.hinden@gmail.com Fri May 13 08:55:53 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 F241CE07B9 for ; Fri, 13 May 2011 08:55:53 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 QNw0nWGm-EHG for ; Fri, 13 May 2011 08:55:53 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 62853E077C for ; Fri, 13 May 2011 08:55:53 -0700 (PDT) Received: by pwi5 with SMTP id 5so1667254pwi.31 for ; Fri, 13 May 2011 08:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=dHsejp3haQuu5nPikgEY3IUL5gZDf4oTXMzKaCJvT00=; b=spID5ynOxJ3IOEiXDa05TA4zT9MdhiDGdxFAP2ezz6NzC2HengeV8+NYhdkADcHnV9 LCXHUKDjd7k0Q8fJTuaOl6XYUpxnRCAlkKUKZsVXfbMpqk1Agcgn1L1nqOt285WMtoWa gRqyvyHrbbCVFV5WWO2HD5bUJtzBe1zm+oNbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=TfxsyOmjzBT9jg2QANfUxIPbk9Okdnzx9iJ8UgSoiAapZzcsZ+Bq1Q1tnGkocn4K9e LeAe1LgdUjlkIVLcG4u/N01DEXMHxihJ8CfGZU/pzMbR+J2iNK/TLUj5GK66NrwVeW9r 8RFJHPHyQLi0nF0hna0MjLe8XmZSZkU485MkI= Received: by 10.143.136.1 with SMTP id o1mr900789wfn.188.1305302153063; Fri, 13 May 2011 08:55:53 -0700 (PDT) Received: from [10.0.0.37] (c-24-130-225-13.hsd1.ca.comcast.net [24.130.225.13]) by mx.google.com with ESMTPS id w14sm2197737wfh.20.2011.05.13.08.55.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2011 08:55:51 -0700 (PDT) Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> Date: Fri, 13 May 2011 08:55:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4462F666-D0FD-45C1-AE71-0CD70580C110@gmail.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org, Bob Hinden 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, 13 May 2011 15:55:54 -0000 Thomas, On May 13, 2011, at 6:37 AM, Thomas Narten wrote: > Per a previous thread, there are indications that the WG may now be > willing to recommend that DHCPv6 be a SHOULD for all hosts. This is > based on the following rationale: >=20 > Thomas Narten writes: >=20 >> I personally would support having DHCP be a SHOULD rather than a >> MAY. The justification in my mind is that if you want the network >> operator to have the choice of whether they want to use Stateless >> addrconf OR DHCP, they only have that choice of devices widely >> implement both. >=20 > This was supported by some others, particularly now that it is clear > there are more implementations of DHCPv6, e.g.: >=20 > Bob Hinden writes: >=20 >> While my personal view is that DHCPv6 won't be used for host >> configuration in cable/DSL deployments (except for provisioning the >> prefix to the home router), it appears that DHCPv6 is being widely >> implemented in host OS's because it is needed some environments. >> There are enough variations in deployment models that a host >> developer will need to support both. >=20 >> Based on this, I think a SHOULD is OK.=20 >=20 > Let me propose the following change be made to the node requirements > document: >=20 > OLD/Current: >=20 > DHCP can be used to obtain and configure addresses. In general, a > network may provide for the configuration of addresses through = Router > Advertisements, DHCP or both. At the present time, the = configuration > of addresses via stateless autoconfiguration is more widely > implemented in hosts than address configuration via DHCP. However, > some environments may require the use of DHCP and may not support = the > configuration of addresses via RAs. Implementations should be aware > of what operating environment their devices will be deployed. Hosts > MAY implement address configuration via DHCP. >=20 > New: >=20 > DHCPv6 can be used to obtain and > configure addresses. In general, a network may provide for the > configuration of addresses through Router Advertisements, > DHCPv6 or both. Some operators have indicated that they do > not intend to support stateless address autoconfiguration on > their networks and will require all address assignments be > made through DHCPv6. On such networks, devices that support > only stateless address autoconfiguration will be unable to > automatically configure addresses. Consequently all hosts > SHOULD implement address configuration via DHCP. >=20 >=20 > Is this acceptable? >=20 > Please respond yes or no. Given the WG's previous hesitation to having > DHCPv6 be a SHOULD, it is important that we get a clear indication of > whether or not the WG supports this change. While I support changing the requirement to a SHOULD, I would prefer the = text to be something like: DHCPv6 can be used to obtain and configure addresses. In general, a network may provide for the configuration of addresses through Router Advertisements, DHCPv6 or both. There will be a wide range of IPv6 deployment = models and differences in address assignment requirements. = Consequently all hosts SHOULD implement address configuration via DHCP. It's not just about what some operators may or may not do. For example = enterprises, governments, etc. will also have specific requirements. Bob From narten@us.ibm.com Fri May 13 09:03:37 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 A8D35E069B for ; Fri, 13 May 2011 09:03:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWg7-FSQj8wy for ; Fri, 13 May 2011 09:03:37 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id 3B694E0685 for ; Fri, 13 May 2011 09:03:37 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4DFnf01010522 for ; Fri, 13 May 2011 09:49:41 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4DG3P0T033168 for ; Fri, 13 May 2011 10:03:25 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4DG3LpY023152 for ; Fri, 13 May 2011 10:03:24 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-244-19.mts.ibm.com [9.65.244.19]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4DG2MRB018453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2011 10:02:24 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4DG2L3L010708; Fri, 13 May 2011 12:02:21 -0400 Message-Id: <201105131602.p4DG2L3L010708@cichlid.raleigh.ibm.com> To: Bob Hinden Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD In-reply-to: <4462F666-D0FD-45C1-AE71-0CD70580C110@gmail.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <4462F666-D0FD-45C1-AE71-0CD70580C110@gmail.com> Comments: In-reply-to Bob Hinden message dated "Fri, 13 May 2011 08:55:48 -0700." Date: Fri, 13 May 2011 12:02:21 -0400 From: Thomas Narten 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, 13 May 2011 16:03:37 -0000 Bob, Bob Hinden writes: > While I support changing the requirement to a SHOULD, I would prefer > the text to be something like: > DHCPv6 can be used to obtain and > configure addresses. In general, a network may provide for the > configuration of addresses through Router Advertisements, > DHCPv6 or both. There will be a wide range of IPv6 deployment models > and differences in address assignment requirements. Consequently all hosts > SHOULD implement address configuration via DHCP. > It's not just about what some operators may or may not do. For > example enterprises, governments, etc. will also have specific > requirements. I like this text better than what I proposed as well. Thanks, Thomas From john.loughney@nokia.com Fri May 13 09:19:10 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 9FD21E067A for ; Fri, 13 May 2011 09:19:10 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZ4CnM3mojK0 for ; Fri, 13 May 2011 09:19:10 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id A25D6E0670 for ; Fri, 13 May 2011 09:19:09 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4DGJ8ik019165; Fri, 13 May 2011 19:19:08 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 19:19:03 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 13 May 2011 18:19:03 +0200 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.183]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0289.008; Fri, 13 May 2011 18:19:02 +0200 From: To: , Subject: RE: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AQHMEXM/7ZYscsi4c0OIKjxfjU/lXpSK53wg Date: Fri, 13 May 2011 16:19:02 +0000 Message-ID: <1571128F4B736C42B743F492521F123B1EAAB8@008-AM1MPN1-003.mgdnok.nokia.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> In-Reply-To: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.243.186.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2011 16:19:03.0501 (UTC) FILETIME=[7996A7D0:01CC1189] X-Nokia-AV: Clean 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, 13 May 2011 16:19:10 -0000 Hi all, In general, I support Thomas' text, but I still think some clarification is= needed: >New: >=20 > DHCPv6 can be used to obtain and > configure addresses. In general, a network may provide for the > configuration of addresses through Router Advertisements, > DHCPv6 or both. Some operators have indicated that they do > not intend to support stateless address autoconfiguration on > their networks and will require all address assignments be > made through DHCPv6. On such networks, devices that support > only stateless address autoconfiguration will be unable to > automatically configure addresses. Consequently all hosts > SHOULD implement address configuration via DHCP. Should we give some guidance on what to do if both mechanisms are available on a network, the methods give contradictory information? I don't think it = is enough to say that both SHOULD be supported, without giving additional clarification on what it means when both are supported. John From rdroms.ietf@gmail.com Fri May 13 09:22: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 A02F0E0736 for ; Fri, 13 May 2011 09:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 hIZ9Jq8vCVTm for ; Fri, 13 May 2011 09:22:43 -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 D0F83E065A for ; Fri, 13 May 2011 09:22:36 -0700 (PDT) Received: by vxg33 with SMTP id 33so2322054vxg.31 for ; Fri, 13 May 2011 09:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=o3hjpt+6YUEdkBTjv2blQ49AELldSP/sMT57+1ddwls=; b=iOAo0jA620LQp2B2VYc3aSaUfBH4qIdjc/wY2iv8k58ohySDAiSZjOOmLjyQVmSBls ILahCR4VCHeoPJ1WL3vAaGsLti+nscUonUp9fSE1CRDc9yVd1fMQe/hBMoI9R9HFif+X H56o52Ep+hFNEFm0gha4T2D8n3giulUJx58uM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=RRzk2XFzM9ThftAONgpCWBFaDJP0E5x1Ke9fgfedNJUChoaHumAhmtJdEsKn7Xmep5 Ai+BL2ShsbRmXuxSUK3fxAL8LrrkuVuq0VKl8LGxhQsgFDL+kvpVn+yv+0zFPCVv/DOK w5ctG1fYmw4egvyeddHu2W2OhsjZvgYuJxwUQ= Received: by 10.52.0.136 with SMTP id 8mr2425147vde.45.1305303754458; Fri, 13 May 2011 09:22:34 -0700 (PDT) Received: from bxb-rdroms-8712.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id i7sm287740vdu.21.2011.05.13.09.22.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2011 09:22:33 -0700 (PDT) Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <201105131602.p4DG2L3L010708@cichlid.raleigh.ibm.com> Date: Fri, 13 May 2011 12:22:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <4462F666-D0FD-45C1-AE71-0CD70580C110@gmail.com> <201105131602.p4DG2L3L010708@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1082) Cc: ipv6@ietf.org, Bob Hinden , Ralph Droms 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, 13 May 2011 16:22:43 -0000 On May 13, 2011, at 12:02 PM 5/13/11, Thomas Narten wrote: > Bob, >=20 > Bob Hinden writes: >=20 >> While I support changing the requirement to a SHOULD, I would prefer >> the text to be something like: >=20 >> DHCPv6 can be used to obtain and >> configure addresses. In general, a network may provide for the >> configuration of addresses through Router Advertisements, >> DHCPv6 or both. There will be a wide range of IPv6 deployment = models >> and differences in address assignment requirements. = Consequently all hosts >> SHOULD implement address configuration via DHCP. >=20 >> It's not just about what some operators may or may not do. For >> example enterprises, governments, etc. will also have specific >> requirements. >=20 > I like this text better than what I proposed as well. Here's my contribution, trying to make an explicit link between the last = two sentences: DHCPv6 can be used to obtain and configure addresses. In general, a network may provide for the configuration of addresses through Router Advertisements, DHCPv6 or both. There will be a wide range of IPv6 deployment models and differences in address assignment requirements, some of which may require DHCPv6 for address assignment. Consequently all hosts SHOULD implement address configuration via DHCPv6. >=20 > Thanks, > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From narten@us.ibm.com Fri May 13 09:26:04 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 DE8C4E0792 for ; Fri, 13 May 2011 09:26:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTDmO2h4p8-j for ; Fri, 13 May 2011 09:26:04 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by ietfa.amsl.com (Postfix) with ESMTP id 4E02FE0776 for ; Fri, 13 May 2011 09:26:04 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4DGHvbn009773 for ; Fri, 13 May 2011 10:17:57 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4DGR0Or056244 for ; Fri, 13 May 2011 10:27:00 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4DAPkex002712 for ; Fri, 13 May 2011 04:25:46 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-244-19.mts.ibm.com [9.65.244.19]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4DAPjp0002682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2011 04:25:45 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4DGPiUT010897; Fri, 13 May 2011 12:25:44 -0400 Message-Id: <201105131625.p4DGPiUT010897@cichlid.raleigh.ibm.com> To: john.loughney@nokia.com Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD In-reply-to: <1571128F4B736C42B743F492521F123B1EAAB8@008-AM1MPN1-003.mgdnok.nokia.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <1571128F4B736C42B743F492521F123B1EAAB8@008-AM1MPN1-003.mgdnok.nokia.com> Comments: In-reply-to message dated "Fri, 13 May 2011 16:19:02 -0000." Date: Fri, 13 May 2011 12:25:44 -0400 From: Thomas Narten 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, 13 May 2011 16:26:05 -0000 Hi John. > Should we give some guidance on what to do if both mechanisms are available > on a network, the methods give contradictory information? I don't think it is > enough to say that both SHOULD be supported, without giving additional > clarification on what it means when both are supported. IMO, it is a bit of a myth that the specs don't say anything to this point. Here is Section 5.6 from RFC 4862: > 5.6. Configuration Consistency > > It is possible for hosts to obtain address information using both > stateless autoconfiguration and DHCPv6 since both may be enabled at > the same time. It is also possible that the values of other > configuration parameters, such as MTU size and hop limit, will be > learned from both Router Advertisements and DHCPv6. If the same > configuration information is provided by multiple sources, the value > of this information should be consistent. However, it is not > considered a fatal error if information received from multiple > sources is inconsistent. Hosts accept the union of all information > received via Neighbor Discovery and DHCPv6. > > If inconsistent information is learned from different sources, an > implementation may want to give information learned securely > precedence over information learned without protection. For > instance, Section 8 of [RFC3971] discusses how to deal with > information learned through Secure Neighbor Discovery conflicting > with information learned through plain Neighbor Discovery. The same > discussion can apply to the preference between information learned > through plain Neighbor Discovery and information learned via secured > DHCPv6, and so on. > > In any case, if there is no security difference, the most recently > obtained values SHOULD have precedence over information learned > earlier. The last sentence is the main one. I also think that dealing with this issue in more detail may not be so easy, and it would be better to do that as updates to those documents (or a standalone document). E.g., even DHCP by itself has a longstanding vagueness about how to handle the merging of information received from running DHCP on different interfaces. (And one reason its hard is that if the two interfaces are in different management domains, there is no easy way to merge the information. We now have a separate WG (MIF) dealing with that sort of thing.) Thomas From rdroms.ietf@gmail.com Fri May 13 09:26:30 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 6A2A3E07BE for ; Fri, 13 May 2011 09:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.849 X-Spam-Level: X-Spam-Status: No, score=-103.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 gqdmYbsB+-SN for ; Fri, 13 May 2011 09:26:29 -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 C6C16E07BD for ; Fri, 13 May 2011 09:26:29 -0700 (PDT) Received: by vxg33 with SMTP id 33so2324831vxg.31 for ; Fri, 13 May 2011 09:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=8t5uCJ0SvaX4Lg7f9dKg9EFj1lJJBvHahfuSZ3skM30=; b=k6Ga3d2yax7iZLJELHTuGUycB+5Dk4kBIMkDllQ+u26+VLnKE8uSpbcpWwyIrvvYSS Ewi4pKVRcBKrgWW/Mo9fgXI84qMgb+Dz7yxpBbPQSiZjjTgOEan3AfPrp+Ptoz31K88C 9DoTa1cAlScppR9ftGhDW21oxGbQNNUX4Jn9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=HIA94A4ohY9jR1bmP8g7MCxxHiLfbhFHqCvlc/qyCVtovGK6rJglxyqE4Ztf0fr2MC UxOPPoh0P/i+o/h0swXDkKAuaGXps2v9BF5XgoaMpo3X/SyisNWE7hYHU+66p/m7/Hw0 X4GY6aWMJBXO4kTcFqak/mGfmyrOKMIdzXOIs= Received: by 10.52.74.37 with SMTP id q5mr2358027vdv.182.1305303989198; Fri, 13 May 2011 09:26:29 -0700 (PDT) Received: from bxb-rdroms-8712.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id cj13sm288374vdb.12.2011.05.13.09.26.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2011 09:26:26 -0700 (PDT) Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <1571128F4B736C42B743F492521F123B1EAAB8@008-AM1MPN1-003.mgdnok.nokia.com> Date: Fri, 13 May 2011 12:26:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <1571128F4B736C42B743F492521F123B1EAAB8@008-AM1MPN1-003.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1082) Cc: narten@us.ibm.com, ipv6@ietf.org, Ralph Droms 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, 13 May 2011 16:26:30 -0000 John... On May 13, 2011, at 12:19 PM 5/13/11, wrote: > Hi all, >=20 > In general, I support Thomas' text, but I still think some = clarification is needed: >=20 >> New: >>=20 >> DHCPv6 can be used to obtain and >> configure addresses. In general, a network may provide for the >> configuration of addresses through Router Advertisements, >> DHCPv6 or both. Some operators have indicated that they do >> not intend to support stateless address autoconfiguration on >> their networks and will require all address assignments be >> made through DHCPv6. On such networks, devices that support >> only stateless address autoconfiguration will be unable to >> automatically configure addresses. Consequently all hosts >> SHOULD implement address configuration via DHCP. >=20 > Should we give some guidance on what to do if both mechanisms are = available > on a network, the methods give contradictory information? I don't = think it is > enough to say that both SHOULD be supported, without giving additional > clarification on what it means when both are supported. I think the IETF has been pretty good about keeping the information from = the two sources independent. Regarding address assignment specifically, = what contradictory information might be provided? I can imagine a node = might get one address from SLAAC and another from DHCPv6, but that's an = acceptable configuration. DHCPv6 doesn't provide prefix information, so = no conflicts there. I don't think there's an issue if DHCPv6 assigns an = address that's not in a prefix advertised in an RA. - Ralph >=20 > John >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From timbeck04@verizon.net Fri May 13 09:28: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 C7B2FE07D3 for ; Fri, 13 May 2011 09:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 FiKBIDlJlpZX for ; Fri, 13 May 2011 09:28:35 -0700 (PDT) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA192E07A8 for ; Fri, 13 May 2011 09:28:35 -0700 (PDT) Received: from bessy ([unknown] [173.48.247.217]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LL500MXU739CG86@vms173001.mailsrvcs.net> for ipv6@ietf.org; Fri, 13 May 2011 11:28:22 -0500 (CDT) Message-id: <96DF83B6DC524A8EA916AA027F27FA4E@bessy> From: "Timothy E. Enos" To: "Thomas Narten" References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Date: Fri, 13 May 2011 12:28:28 -0400 MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 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, 13 May 2011 16:28:36 -0000 Hi Thomas, Thanks for posting this. IMO, a SHOULD is not required in a SOHO environment (which is arguably not a corner case for deployment). MAY works. Just as some environments may require the use of DHCPv6, some environments may not. For those that require use of DHCPv6, they MAY use it. I think at least in the SOHO context, it's really the local administrative policies (not hard and fast technical factors) that determine the (lack of) need for DHCPv6. All the above said, my personal opinion is that DHCPv6 does not need to elevated to SHOULD from MAY for the node requirements spec. If the group decides to the contrary I can certainly accept that. My $0.02, Tim Ps 127:3-5 ----- Original Message ----- From: "Thomas Narten" To: Sent: Friday, May 13, 2011 9:37 AM Subject: Node Requirements: Elevating DHCPv6 from MAY to SHOULD > Per a previous thread, there are indications that the WG may now be > willing to recommend that DHCPv6 be a SHOULD for all hosts. This is > based on the following rationale: > > Thomas Narten writes: > >> I personally would support having DHCP be a SHOULD rather than a >> MAY. The justification in my mind is that if you want the network >> operator to have the choice of whether they want to use Stateless >> addrconf OR DHCP, they only have that choice of devices widely >> implement both. > > This was supported by some others, particularly now that it is clear > there are more implementations of DHCPv6, e.g.: > > Bob Hinden writes: > >> While my personal view is that DHCPv6 won't be used for host >> configuration in cable/DSL deployments (except for provisioning the >> prefix to the home router), it appears that DHCPv6 is being widely >> implemented in host OS's because it is needed some environments. >> There are enough variations in deployment models that a host >> developer will need to support both. > >> Based on this, I think a SHOULD is OK. > > Let me propose the following change be made to the node requirements > document: > > OLD/Current: > > DHCP can be used to obtain and configure addresses. In general, a > network may provide for the configuration of addresses through Router > Advertisements, DHCP or both. At the present time, the configuration > of addresses via stateless autoconfiguration is more widely > implemented in hosts than address configuration via DHCP. However, > some environments may require the use of DHCP and may not support the > configuration of addresses via RAs. Implementations should be aware > of what operating environment their devices will be deployed. Hosts > MAY implement address configuration via DHCP. > > New: > > DHCPv6 can be used to obtain and > configure addresses. In general, a network may provide for the > configuration of addresses through Router Advertisements, > DHCPv6 or both. Some operators have indicated that they do > not intend to support stateless address autoconfiguration on > their networks and will require all address assignments be > made through DHCPv6. On such networks, devices that support > only stateless address autoconfiguration will be unable to > automatically configure addresses. Consequently all hosts > SHOULD implement address configuration via DHCP. > > > Is this acceptable? > > Please respond yes or no. Given the WG's previous hesitation to having > DHCPv6 be a SHOULD, it is important that we get a clear indication of > whether or not the WG supports this change. > > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From bob.hinden@gmail.com Fri May 13 09:40: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 19CE3E06A6 for ; Fri, 13 May 2011 09:40: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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 SWSODcJez+OZ for ; Fri, 13 May 2011 09:40:08 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 632C0E0659 for ; Fri, 13 May 2011 09:40:08 -0700 (PDT) Received: by pwi5 with SMTP id 5so1689002pwi.31 for ; Fri, 13 May 2011 09:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :x-priority:in-reply-to:date:cc:content-transfer-encoding:message-id :references:to:x-mailer; bh=E8fQ0hN3Ze5hgitPyZLcyd5hfau/QbYemA6ZHAIEnrI=; b=Fx23ijjjmoII4H5RSCZJnHUJ1yK4vv2FZvWr1uSjx58YDDccJbUGRqF99awWGluFgQ oXZcFYenp530NTdj6XRNUCvysvvEv0Za65Tke+2Ho8pABL7epDHlkmaDmKIdMApi2ejx WcqDdKidgfVWFWIB4uREwQkTELryva/kcVhPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; b=LQ0MMH2wbOXJZ1i8l1KELv86FOMQNaqI7C0Qb83X9GxRXaJXXEWMUkVVQWYW4nyZoh IaL4xpre9oGuifodYZvsAyOrYYJN7cC4xArSMC0SOj/XmOtGTk+uNlNuYiEAGCwEIO9z bkjDQ6trhoJJHTPprTJHIO6DWdFYrub5BlmSo= Received: by 10.68.65.68 with SMTP id v4mr2482141pbs.158.1305304808071; Fri, 13 May 2011 09:40:08 -0700 (PDT) Received: from [10.0.0.37] (c-24-130-225-13.hsd1.ca.comcast.net [24.130.225.13]) by mx.google.com with ESMTPS id s5sm1456855pba.64.2011.05.13.09.40.04 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2011 09:40:05 -0700 (PDT) Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden X-Priority: 3 In-Reply-To: <96DF83B6DC524A8EA916AA027F27FA4E@bessy> Date: Fri, 13 May 2011 09:40:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <78BCA97B-E2C0-4527-A4A0-6578911800EF@gmail.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <96DF83B6DC524A8EA916AA027F27FA4E@bessy> To: Timothy E. Enos X-Mailer: Apple Mail (2.1084) Cc: Thomas Narten , ipv6@ietf.org, Bob Hinden 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, 13 May 2011 16:40:09 -0000 Timothy, On May 13, 2011, at 9:28 AM, Timothy E. Enos wrote: > Hi Thomas, >=20 > Thanks for posting this. >=20 > IMO, a SHOULD is not required in a SOHO environment (which is arguably = not a corner case for deployment). MAY works. >=20 > Just as some environments may require the use of DHCPv6, some = environments may not. >=20 > For those that require use of DHCPv6, they MAY use it. >=20 > I think at least in the SOHO context, it's really the local = administrative policies (not hard and fast technical factors) that = determine the (lack of) need for DHCPv6. >=20 > All the above said, my personal opinion is that DHCPv6 does not need = to elevated to SHOULD from MAY for the node requirements spec. If the = group decides to the contrary I can certainly accept that. I think all we are trying to say that there are a wide range of = deployment models, that we recommend that hosts SHOULD support both. We = are not making any statement about what should be used in a particular = deployment. Or at least, that's my thinking and why I support the SHOULD. Also, why = I suggested changing the text to not talk about "operators". Bob >=20 > My $0.02, >=20 > Tim > Ps 127:3-5 >=20 > ----- Original Message ----- From: "Thomas Narten" > To: > Sent: Friday, May 13, 2011 9:37 AM > Subject: Node Requirements: Elevating DHCPv6 from MAY to SHOULD >=20 >=20 >> Per a previous thread, there are indications that the WG may now be >> willing to recommend that DHCPv6 be a SHOULD for all hosts. This is >> based on the following rationale: >>=20 >> Thomas Narten writes: >>=20 >>> I personally would support having DHCP be a SHOULD rather than a >>> MAY. The justification in my mind is that if you want the network >>> operator to have the choice of whether they want to use Stateless >>> addrconf OR DHCP, they only have that choice of devices widely >>> implement both. >>=20 >> This was supported by some others, particularly now that it is clear >> there are more implementations of DHCPv6, e.g.: >>=20 >> Bob Hinden writes: >>=20 >>> While my personal view is that DHCPv6 won't be used for host >>> configuration in cable/DSL deployments (except for provisioning the >>> prefix to the home router), it appears that DHCPv6 is being widely >>> implemented in host OS's because it is needed some environments. >>> There are enough variations in deployment models that a host >>> developer will need to support both. >>=20 >>> Based on this, I think a SHOULD is OK. >>=20 >> Let me propose the following change be made to the node requirements >> document: >>=20 >> OLD/Current: >>=20 >> DHCP can be used to obtain and configure addresses. In general, a >> network may provide for the configuration of addresses through = Router >> Advertisements, DHCP or both. At the present time, the = configuration >> of addresses via stateless autoconfiguration is more widely >> implemented in hosts than address configuration via DHCP. However, >> some environments may require the use of DHCP and may not support = the >> configuration of addresses via RAs. Implementations should be aware >> of what operating environment their devices will be deployed. Hosts >> MAY implement address configuration via DHCP. >>=20 >> New: >>=20 >> DHCPv6 can be used to obtain and >> configure addresses. In general, a network may provide for the >> configuration of addresses through Router Advertisements, >> DHCPv6 or both. Some operators have indicated that they do >> not intend to support stateless address autoconfiguration on >> their networks and will require all address assignments be >> made through DHCPv6. On such networks, devices that support >> only stateless address autoconfiguration will be unable to >> automatically configure addresses. Consequently all hosts >> SHOULD implement address configuration via DHCP. >>=20 >>=20 >> Is this acceptable? >>=20 >> Please respond yes or no. Given the WG's previous hesitation to = having >> DHCPv6 be a SHOULD, it is important that we get a clear indication of >> whether or not the WG supports this change. >>=20 >> Thomas >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> --------------------------------------------------------------------=20= >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From swmike@swm.pp.se Fri May 13 09:48:49 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 BB726E080A for ; Fri, 13 May 2011 09:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 bWJFL8sSGCrH for ; Fri, 13 May 2011 09:48:49 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5C4E080B for ; Fri, 13 May 2011 09:48:34 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 877D99C; Fri, 13 May 2011 18:48:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 844979A for ; Fri, 13 May 2011 18:48:31 +0200 (CEST) Date: Fri, 13 May 2011 18:48:31 +0200 (CEST) From: Mikael Abrahamsson To: ipv6@ietf.org Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD In-Reply-To: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> Message-ID: References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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, 13 May 2011 16:48:49 -0000 On Fri, 13 May 2011, Thomas Narten wrote: > Per a previous thread, there are indications that the WG may now be > willing to recommend that DHCPv6 be a SHOULD for all hosts. This is > based on the following rationale: I support moving it to SHOULD. -- Mikael Abrahamsson email: swmike@swm.pp.se From john.loughney@nokia.com Fri May 13 09:48: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 0BA10E080A for ; Fri, 13 May 2011 09:48:58 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-KCAMxiQoo1 for ; Fri, 13 May 2011 09:48:57 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id E8B44E0805 for ; Fri, 13 May 2011 09:48:53 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4DGmpPb022873; Fri, 13 May 2011 19:48:51 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 19:48:51 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 13 May 2011 18:48:50 +0200 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.183]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0289.008; Fri, 13 May 2011 18:48:50 +0200 From: To: , Subject: RE: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AQHMEYrK7ZYscsi4c0OIKjxfjU/lXpSK93+Q Date: Fri, 13 May 2011 16:48:50 +0000 Message-ID: <1571128F4B736C42B743F492521F123B1EAB5C@008-AM1MPN1-003.mgdnok.nokia.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <96DF83B6DC524A8EA916AA027F27FA4E@bessy> In-Reply-To: <96DF83B6DC524A8EA916AA027F27FA4E@bessy> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.243.186.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2011 16:48:51.0507 (UTC) FILETIME=[A352B830:01CC118D] X-Nokia-AV: Clean 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, 13 May 2011 16:48:58 -0000 Tim, I think we are talking about the need of supporting DHCPv6, not the use of = DHCPv6. Nodes that are in a SOHO environment may not need to use DHCPv6, bu= t if those nodes also move outside of the SOHO network, they might need DHC= Pv6 in other networks. IMO, the ability to support both DHCPv6 or stateless= address autoconfig is a very good thing for nodes, as it can be quite diff= icult to know what exact networks a node might attach to. John -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of ext= Timothy E. Enos Sent: Friday, May 13, 2011 9:28 AM To: Thomas Narten Cc: ipv6@ietf.org Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Hi Thomas, Thanks for posting this. IMO, a SHOULD is not required in a SOHO environment (which is arguably not = a corner case for deployment). MAY works. Just as some environments may require the use of DHCPv6, some environments = may not. For those that require use of DHCPv6, they MAY use it. I think at least in the SOHO context, it's really the local administrative = policies (not hard and fast technical factors) that determine the (lack of)= need for DHCPv6. All the above said, my personal opinion is that DHCPv6 does not need to ele= vated to SHOULD from MAY for the node requirements spec. If the group decid= es to the contrary I can certainly accept that. My $0.02, Tim Ps 127:3-5 ----- Original Message ----- From: "Thomas Narten" To: Sent: Friday, May 13, 2011 9:37 AM Subject: Node Requirements: Elevating DHCPv6 from MAY to SHOULD > Per a previous thread, there are indications that the WG may now be > willing to recommend that DHCPv6 be a SHOULD for all hosts. This is > based on the following rationale: > > Thomas Narten writes: > >> I personally would support having DHCP be a SHOULD rather than a >> MAY. The justification in my mind is that if you want the network >> operator to have the choice of whether they want to use Stateless >> addrconf OR DHCP, they only have that choice of devices widely >> implement both. > > This was supported by some others, particularly now that it is clear > there are more implementations of DHCPv6, e.g.: > > Bob Hinden writes: > >> While my personal view is that DHCPv6 won't be used for host >> configuration in cable/DSL deployments (except for provisioning the >> prefix to the home router), it appears that DHCPv6 is being widely >> implemented in host OS's because it is needed some environments. >> There are enough variations in deployment models that a host >> developer will need to support both. > >> Based on this, I think a SHOULD is OK. > > Let me propose the following change be made to the node requirements > document: > > OLD/Current: > > DHCP can be used to obtain and configure addresses. In general, a > network may provide for the configuration of addresses through Router > Advertisements, DHCP or both. At the present time, the configuration > of addresses via stateless autoconfiguration is more widely > implemented in hosts than address configuration via DHCP. However, > some environments may require the use of DHCP and may not support the > configuration of addresses via RAs. Implementations should be aware > of what operating environment their devices will be deployed. Hosts > MAY implement address configuration via DHCP. > > New: > > DHCPv6 can be used to obtain and > configure addresses. In general, a network may provide for the > configuration of addresses through Router Advertisements, > DHCPv6 or both. Some operators have indicated that they do > not intend to support stateless address autoconfiguration on > their networks and will require all address assignments be > made through DHCPv6. On such networks, devices that support > only stateless address autoconfiguration will be unable to > automatically configure addresses. Consequently all hosts > SHOULD implement address configuration via DHCP. > > > Is this acceptable? > > Please respond yes or no. Given the WG's previous hesitation to having > DHCPv6 be a SHOULD, it is important that we get a clear indication of > whether or not the WG supports this change. > > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------=20 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From john.loughney@nokia.com Fri May 13 09:50: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 DDFCEE06E0 for ; Fri, 13 May 2011 09:50:39 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yZJ6+4eIS5E for ; Fri, 13 May 2011 09:50:38 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1083AE0729 for ; Fri, 13 May 2011 09:50:26 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4DGoDSF003781; Fri, 13 May 2011 19:50:23 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 19:50:18 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 13 May 2011 18:50:17 +0200 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.183]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0289.008; Fri, 13 May 2011 18:50:17 +0200 From: To: Subject: RE: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AQHMEXM/7ZYscsi4c0OIKjxfjU/lXpSK53wg///pFACAACfnEA== Date: Fri, 13 May 2011 16:50:16 +0000 Message-ID: <1571128F4B736C42B743F492521F123B1EAB72@008-AM1MPN1-003.mgdnok.nokia.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <1571128F4B736C42B743F492521F123B1EAAB8@008-AM1MPN1-003.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.243.186.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2011 16:50:18.0829 (UTC) FILETIME=[D75EFFD0:01CC118D] X-Nokia-AV: Clean Cc: narten@us.ibm.com, 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, 13 May 2011 16:50:40 -0000 Hi Ralph, > I think the IETF has been pretty good about keeping the information from = the two sources independent. Regarding address assignment specifically, wh= at=20 > contradictory information might be provided? I can imagine a node might = get one address from SLAAC and another from DHCPv6, but that's an acceptabl= e > configuration. DHCPv6 doesn't provide prefix information, so no conflic= ts there. I don't think there's an issue if DHCPv6 assigns an address that= 's not in a prefix=20 > advertised in an RA. You are right, Thomas' text is enough for me. John From john.loughney@nokia.com Fri May 13 09:51:49 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 877B3E081F for ; Fri, 13 May 2011 09:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 gKOwhUh096pD for ; Fri, 13 May 2011 09:51:49 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8385AE0812 for ; Fri, 13 May 2011 09:51:37 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4DGpKIk001722; Fri, 13 May 2011 19:51:36 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 19:51:21 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 13 May 2011 18:51:20 +0200 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.183]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0289.008; Fri, 13 May 2011 18:51:20 +0200 From: To: Subject: RE: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AQHMEXM/7ZYscsi4c0OIKjxfjU/lXpSK53wg///o5wCAAChyUA== Date: Fri, 13 May 2011 16:51:19 +0000 Message-ID: <1571128F4B736C42B743F492521F123B1EAB83@008-AM1MPN1-003.mgdnok.nokia.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <1571128F4B736C42B743F492521F123B1EAAB8@008-AM1MPN1-003.mgdnok.nokia.com> <201105131625.p4DGPiUT010897@cichlid.raleigh.ibm.com> In-Reply-To: <201105131625.p4DGPiUT010897@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.243.186.190] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2011 16:51:21.0610 (UTC) FILETIME=[FCCA9EA0:01CC118D] X-Nokia-AV: Clean 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, 13 May 2011 16:51:49 -0000 > I also think that dealing with this issue in more detail may not be so ea= sy, and it would be better to do that as updates to those documents (or a s= tandalone=20 >document). > > E.g., even DHCP by itself has a longstanding vagueness about how to handl= e the merging of information received from running DHCP on different interf= aces. (And=20 > one reason its hard is that if the two interfaces are in different manage= ment domains, there is no easy way to merge the information. We now have a = separate WG=20 > (MIF) dealing with that sort of thing.) Agreed, and I don't think the Node Requirements doc is the place to provide= this kind of clarification. From Basavaraj.Patil@nokia.com Fri May 13 10:12: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 71F83E070C for ; Fri, 13 May 2011 10:12:39 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXn0h4QNbR-9 for ; Fri, 13 May 2011 10:12:38 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 65317E068E for ; Fri, 13 May 2011 10:12:38 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4DHCaOZ015405; Fri, 13 May 2011 20:12:36 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 20:12:35 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 13 May 2011 19:12:35 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.125]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0289.008; Fri, 13 May 2011 19:12:35 +0200 From: To: , Subject: RE: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AQHMEXM/ZfKIkYxUoEGBNHFgX3zbhZSKyAYAgAA20PA= Date: Fri, 13 May 2011 17:12:34 +0000 Message-ID: <21E7D9BD69CC7241AAE00F4EA183B719039A8A@008-AM1MPN1-024.mgdnok.nokia.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <4462F666-D0FD-45C1-AE71-0CD70580C110@gmail.com> In-Reply-To: <4462F666-D0FD-45C1-AE71-0CD70580C110@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.59.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2011 17:12:35.0946 (UTC) FILETIME=[F45ADCA0:01CC1190] X-Nokia-AV: Clean 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, 13 May 2011 17:12:39 -0000 I support elevating the requirement for DHCPv6 on nodes to a SHOULD.=20 Bob's proposed text looks fine. -Raj -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of ext= Bob Hinden Sent: Friday, May 13, 2011 10:56 AM To: Thomas Narten Cc: ipv6@ietf.org; Bob Hinden Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thomas, On May 13, 2011, at 6:37 AM, Thomas Narten wrote: > Per a previous thread, there are indications that the WG may now be=20 > willing to recommend that DHCPv6 be a SHOULD for all hosts. This is=20 > based on the following rationale: >=20 > Thomas Narten writes: >=20 >> I personally would support having DHCP be a SHOULD rather than a MAY.=20 >> The justification in my mind is that if you want the network operator=20 >> to have the choice of whether they want to use Stateless addrconf OR=20 >> DHCP, they only have that choice of devices widely implement both. >=20 > This was supported by some others, particularly now that it is clear=20 > there are more implementations of DHCPv6, e.g.: >=20 > Bob Hinden writes: >=20 >> While my personal view is that DHCPv6 won't be used for host=20 >> configuration in cable/DSL deployments (except for provisioning the=20 >> prefix to the home router), it appears that DHCPv6 is being widely=20 >> implemented in host OS's because it is needed some environments. >> There are enough variations in deployment models that a host=20 >> developer will need to support both. >=20 >> Based on this, I think a SHOULD is OK.=20 >=20 > Let me propose the following change be made to the node requirements > document: >=20 > OLD/Current: >=20 > DHCP can be used to obtain and configure addresses. In general, a > network may provide for the configuration of addresses through Router > Advertisements, DHCP or both. At the present time, the configuration > of addresses via stateless autoconfiguration is more widely > implemented in hosts than address configuration via DHCP. However, > some environments may require the use of DHCP and may not support the > configuration of addresses via RAs. Implementations should be aware > of what operating environment their devices will be deployed. Hosts > MAY implement address configuration via DHCP. >=20 > New: >=20 > DHCPv6 can be used to obtain and > configure addresses. In general, a network may provide for the > configuration of addresses through Router Advertisements, > DHCPv6 or both. Some operators have indicated that they do > not intend to support stateless address autoconfiguration on > their networks and will require all address assignments be > made through DHCPv6. On such networks, devices that support > only stateless address autoconfiguration will be unable to > automatically configure addresses. Consequently all hosts > SHOULD implement address configuration via DHCP. >=20 >=20 > Is this acceptable? >=20 > Please respond yes or no. Given the WG's previous hesitation to having > DHCPv6 be a SHOULD, it is important that we get a clear indication of=20 > whether or not the WG supports this change. While I support changing the requirement to a SHOULD, I would prefer the te= xt to be something like: DHCPv6 can be used to obtain and configure addresses. In general, a network may provide for the configuration of addresses through Router Advertisements, DHCPv6 or both. There will be a wide range of IPv6 deployment models and differences in address assignment requirements. Consequently a= ll hosts SHOULD implement address configuration via DHCP. It's not just about what some operators may or may not do. For example ent= erprises, governments, etc. will also have specific requirements. Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From christopher.morrow@gmail.com Fri May 13 10:29:16 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 1EB4BE0682 for ; Fri, 13 May 2011 10:29:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfsIVzy7m5cx for ; Fri, 13 May 2011 10:29:15 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 30944E065A for ; Fri, 13 May 2011 10:29:15 -0700 (PDT) Received: by wyb29 with SMTP id 29so2455902wyb.31 for ; Fri, 13 May 2011 10:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YyqeYbZofwZEkPlgtV2qP6LJbNJjZoGMm7uAFaEXGco=; b=S6YvBboJnFA9LMB9R2/8nLqSO/sBSyHhVed5I3t7G8qNaBfcmCA27YNtq1O5YEruhh t5sM/iVxQWhCCl9vrA9sRfTXXBmqaM5BnpS+eddOiEFj7Htva/nNzk3lHv2r86YQD/fN lBIZGlJhtYleB/vEbLJJOqwIORbmENCmQCB48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EBA0i2++oRNldOZZj4qzpLds6PX7x9gtnH86uC/FIp7PbjGdUbkbelVU7GumKrgsdD BPTqcrJiGndQVUtSPl59Ocv/SUSKmqndlwLApxOHJZiuhm4lThnv9gVGV298TKvQV2bv jM6jiVMLvHgCRVEt7CwIgijLESIVq+Op655W4= MIME-Version: 1.0 Received: by 10.216.221.72 with SMTP id q50mr1581061wep.99.1305307754306; Fri, 13 May 2011 10:29:14 -0700 (PDT) Received: by 10.216.26.141 with HTTP; Fri, 13 May 2011 10:29:14 -0700 (PDT) In-Reply-To: <21E7D9BD69CC7241AAE00F4EA183B719039A8A@008-AM1MPN1-024.mgdnok.nokia.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <4462F666-D0FD-45C1-AE71-0CD70580C110@gmail.com> <21E7D9BD69CC7241AAE00F4EA183B719039A8A@008-AM1MPN1-024.mgdnok.nokia.com> Date: Fri, 13 May 2011 13:29:14 -0400 Message-ID: Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: Christopher Morrow To: Basavaraj.Patil@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Cc: narten@us.ibm.com, ipv6@ietf.org, bob.hinden@gmail.com 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, 13 May 2011 17:29:16 -0000 On Fri, May 13, 2011 at 1:12 PM, wrote: > > I support elevating the requirement for DHCPv6 on nodes to a SHOULD. +1 (and thanks!) From wbeebee@cisco.com Fri May 13 10:46: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 8A61EE073D for ; Fri, 13 May 2011 10:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 UYaXpr9WiCk4 for ; Fri, 13 May 2011 10:45:59 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id 49908E0764 for ; Fri, 13 May 2011 10:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=3487; q=dns/txt; s=iport; t=1305308759; x=1306518359; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=CJHmHNBq3hG1kQyfYlVYksUvO5lQQhzq8p5nslvA2+w=; b=miLOf7xf3dyI4+FiJNlIFxqnt6pDUv1Pi5JTnTikp1c4hn3lZRUIV93h jUAPWH6LBDCAbHXCa3z0t7lBuE5M7qQb+CFVrTud16nycqY479KjpJLt2 HgeRQuk5Aol+jRf1NeIcx9/2i4SiKqgNWwz2OJHt3sJ4EMGVTOfUn7cQ0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMGAL9tzU2tJV2c/2dsb2JhbACCZIY7nAZjAneIcJ58ng2GFQSQBoQ4hmmDbQ X-IronPort-AV: E=Sophos;i="4.64,365,1301875200"; d="scan'208,217";a="232942911" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 13 May 2011 17:45:58 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p4DHjwYl030352; Fri, 13 May 2011 17:45:58 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 12:45:58 -0500 Received: from 161.44.175.134 ([161.44.175.134]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 May 2011 17:45:57 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 13 May 2011 13:45:56 -0400 Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: Wes Beebee To: Cameron Byrne , Thomas Narten Message-ID: Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AcwRlZx62FmSYIBMt0+ZoOJ5cP/lsQ== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3388139157_1141138" X-OriginalArrivalTime: 13 May 2011 17:45:58.0008 (UTC) FILETIME=[9DAD4780:01CC1195] 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, 13 May 2011 17:46:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3388139157_1141138 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable >> New: >> >> =A0 =A0 =A0 =A0 DHCPv6 can be used to obtain and >> =A0 =A0 =A0 =A0configure addresses. In general, a network may provide for the >> =A0 =A0 =A0 =A0configuration of addresses through Router Advertisements, >> =A0 =A0 =A0 =A0DHCPv6 or both. =A0Some operators have indicated that they do >> =A0 =A0 =A0 =A0not intend to support stateless address autoconfiguration on >> =A0 =A0 =A0 =A0their networks and will require all address assignments be >> =A0 =A0 =A0 =A0made through DHCPv6. On such networks, devices that support >> =A0 =A0 =A0 =A0only stateless address autoconfiguration will be unable to >> =A0 =A0 =A0 =A0automatically configure addresses. Consequently all hosts >> =A0 =A0 =A0 =A0SHOULD implement address configuration via DHCP. >> >> >> Is this acceptable? >> >> Please respond yes or no. Given the WG's previous hesitation to having >> DHCPv6 be a SHOULD, it is important that we get a clear indication of >> whether or not the WG supports this change. >> > Yes. I support the new text. +1=20 Note that this is a MUST for equipment in Cable networks, although I do understand that there will be significant networks that won=B9t rely on DHCPv= 6 in other deployment scenarios. - Wes --B_3388139157_1141138 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD >> New:
>>
>> =A0 =A0 =A0 =A0<t> DHCPv6 <xref target=3D'RFC3315' /> can be use= d to obtain and
>> =A0 =A0 =A0 =A0configure addresses. In general, a network may provide for = the
>> =A0 =A0 =A0 =A0configuration of addresses through Router Advertisements, >> =A0 =A0 =A0 =A0DHCPv6 or both. =A0Some operators have indicated that they do=
>> =A0 =A0 =A0 =A0not intend to support stateless address autoconfiguration o= n
>> =A0 =A0 =A0 =A0their networks and will require all address assignments be<= BR> >> =A0 =A0 =A0 =A0made through DHCPv6. On such networks, devices that support=
>> =A0 =A0 =A0 =A0only stateless address autoconfiguration will be unable to<= BR> >> =A0 =A0 =A0 =A0automatically configure addresses. Consequently all hosts >> =A0 =A0 =A0 =A0SHOULD implement address configuration via DHCP.</t><= BR> >>
>>
>> Is this acceptable?
>>
>> Please respond yes or no. Given the WG's previous hesitation to ha= ving
>> DHCPv6 be a SHOULD, it is important that we get a clear indication= of
>> whether or not the WG supports this change.
>>

> Yes. I support the new text.

+1

Note that this is a MUST for equipment in Cable networks, although I do und= erstand that there will be significant networks that won’t rely on DHC= Pv6 in other deployment scenarios.

- Wes --B_3388139157_1141138-- From alexandru.petrescu@gmail.com Fri May 13 11:04:56 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 42093E0847 for ; Fri, 13 May 2011 11:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=0.604, 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 88YR+rap2SHb for ; Fri, 13 May 2011 11:04:55 -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 71AE3E0846 for ; Fri, 13 May 2011 11:04:55 -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 p4DI4r3a021207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 May 2011 20:04:53 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p4DI4rj1009295; Fri, 13 May 2011 20:04:53 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p4DI4qgs030190; Fri, 13 May 2011 20:04:53 +0200 Message-ID: <4DCD72C4.2070806@gmail.com> Date: Fri, 13 May 2011 20:04:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <1571128F4B736C42B743F492521F123B1EAAB8@008-AM1MPN1-003.mgdnok.nokia.com> <201105131625.p4DGPiUT010897@cichlid.raleigh.ibm.com> In-Reply-To: <201105131625.p4DGPiUT010897@cichlid.raleigh.ibm.com> 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: Fri, 13 May 2011 18:04:56 -0000 Le 13/05/2011 18:25, Thomas Narten a écrit : > Hi John. > >> Should we give some guidance on what to do if both mechanisms are available >> on a network, the methods give contradictory information? I don't think it is >> enough to say that both SHOULD be supported, without giving additional >> clarification on what it means when both are supported. > > IMO, it is a bit of a myth that the specs don't say anything to this > point. > > Here is Section 5.6 from RFC 4862: > >> 5.6. Configuration Consistency >> >> It is possible for hosts to obtain address information using both >> stateless autoconfiguration and DHCPv6 since both may be enabled at >> the same time. It is also possible that the values of other >> configuration parameters, such as MTU size and hop limit, will be >> learned from both Router Advertisements and DHCPv6. If the same >> configuration information is provided by multiple sources, the value >> of this information should be consistent. However, it is not >> considered a fatal error if information received from multiple >> sources is inconsistent. Hosts accept the union of all information >> received via Neighbor Discovery and DHCPv6. >> >> If inconsistent information is learned from different sources, an >> implementation may want to give information learned securely >> precedence over information learned without protection. For >> instance, Section 8 of [RFC3971] discusses how to deal with >> information learned through Secure Neighbor Discovery conflicting >> with information learned through plain Neighbor Discovery. The same >> discussion can apply to the preference between information learned >> through plain Neighbor Discovery and information learned via secured >> DHCPv6, and so on. >> >> In any case, if there is no security difference, the most recently >> obtained values SHOULD have precedence over information learned >> earlier. > > The last sentence is the main one. > > I also think that dealing with this issue in more detail may not be so > easy, and it would be better to do that as updates to those documents > (or a standalone document). > > E.g., even DHCP by itself has a longstanding vagueness about how to > handle the merging of information received from running DHCP on > different interfaces. (And one reason its hard is that if the two > interfaces are in different management domains, there is no easy way > to merge the information. We now have a separate WG (MIF) dealing with > that sort of thing.) YEs have we a WG item in that group dealing with that sort of thing - but it is not yet solved, at least with respect to the default route: - should the lifetime of the default route sent by DHCP be 32 or 16bit long? (ND prefers the latter DHCP the former). (your dhcp-should text seems to be saying operators dont like RA for some cases, hence they dont know how to configure the default route for these cases, hence DHCP should, and MIF doesnt lifetime). Etc. Alex > > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From alexandru.petrescu@gmail.com Fri May 13 11: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 2EF80E07E2 for ; Fri, 13 May 2011 11:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6] 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 8EG9360Bp7B0 for ; Fri, 13 May 2011 11:11:16 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5444CE0791 for ; Fri, 13 May 2011 11:11:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p4DIBE1T032561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 May 2011 20:11:14 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p4DIBDWP010377; Fri, 13 May 2011 20:11:14 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p4DIBDpw031610; Fri, 13 May 2011 20:11:13 +0200 Message-ID: <4DCD7441.4000602@gmail.com> Date: Fri, 13 May 2011 20:11:13 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Thomas Narten Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> In-Reply-To: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 13 May 2011 18:11:17 -0000 Le 13/05/2011 15:37, Thomas Narten a écrit : > Per a previous thread, there are indications that the WG may now be > willing to recommend that DHCPv6 be a SHOULD for all hosts. This is > based on the following rationale: > > Thomas Narten writes: > >> I personally would support having DHCP be a SHOULD rather than a >> MAY. The justification in my mind is that if you want the network >> operator to have the choice of whether they want to use Stateless >> addrconf OR DHCP, they only have that choice of devices widely >> implement both. > > This was supported by some others, particularly now that it is clear > there are more implementations of DHCPv6, e.g.: > > Bob Hinden writes: > >> While my personal view is that DHCPv6 won't be used for host >> configuration in cable/DSL deployments (except for provisioning the >> prefix to the home router), it appears that DHCPv6 is being widely >> implemented in host OS's because it is needed some environments. >> There are enough variations in deployment models that a host >> developer will need to support both. > >> Based on this, I think a SHOULD is OK. > > Let me propose the following change be made to the node requirements > document: > > OLD/Current: > > DHCP can be used to obtain and configure addresses. In general, a > network may provide for the configuration of addresses through Router > Advertisements, DHCP or both. At the present time, the configuration > of addresses via stateless autoconfiguration is more widely > implemented in hosts than address configuration via DHCP. However, > some environments may require the use of DHCP and may not support the > configuration of addresses via RAs. Implementations should be aware > of what operating environment their devices will be deployed. Hosts > MAY implement address configuration via DHCP. > > New: > > DHCPv6 can be used to obtain and > configure addresses. In general, a network may provide for the > configuration of addresses through Router Advertisements, > DHCPv6 or both. Some operators have indicated that they do > not intend to support stateless address autoconfiguration on > their networks and will require all address assignments be > made through DHCPv6. On such networks, devices that support > only stateless address autoconfiguration will be unable to > automatically configure addresses. Consequently all hosts > SHOULD implement address configuration via DHCP. YEs I support this text as a SHOULD DHCP. I have several positive reasons for that, related to efficient auto-configuration in vehicular environments, moving networks using prefix delegation - better use just one DHCP, instead of mixed DHCP+RA, etc. But there are also unknowns: we still dont know how to configure a default route using DHCPv6. One issue is the lifetime field (Default Router List structure of ND implementation, and RA, use 16bit lifetimes for the Default Router, MIF-DHCP draft doesnt say how long a lifetime is, and DHCP lifetime fields are typically 32bit). These aspects may be under discussion but until solved we dont know. (I know here locally, but may be different at yours). There are other issues. Alex > > > Is this acceptable? > > Please respond yes or no. Given the WG's previous hesitation to having > DHCPv6 be a SHOULD, it is important that we get a clear indication of > whether or not the WG supports this change. > > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From night@nist.gov Fri May 13 11:16:04 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 61CC1E0791 for ; Fri, 13 May 2011 11:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vhIqfHK5PHsc for ; Fri, 13 May 2011 11:16:03 -0700 (PDT) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by ietfa.amsl.com (Postfix) with ESMTP id 65AB1E07B6 for ; Fri, 13 May 2011 11:16:03 -0700 (PDT) Received: from [127.0.0.1] (81-140.antd.nist.gov [129.6.140.81]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p4DIFOaR030340; Fri, 13 May 2011 14:15:52 -0400 Message-ID: <4DCD753C.3010205@nist.gov> Date: Fri, 13 May 2011 14:15:24 -0400 From: Stephen Nightingale User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "usgv6-testing@nist.gov" , "usgv6-labs@NIST.GOV" , "nav6tf@ipv6forum.com" , IPv6 TWG , ipv6@ietf.org Subject: USGv6 Version 2.0 Call For Community Input Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: night@nist.gov X-Mailman-Approved-At: Fri, 13 May 2011 11:25:03 -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, 13 May 2011 18:16:04 -0000 Original announcement at: http://www.antd.nist.gov/usgv6/index.html Together with the Comments spreadsheet, text of USGv6 version 1.0, and the testing documents. ====================== USGv6 Version 2.0 Call For Community Input In response to OMB directives the National Institute of Standards and Technology (NIST) developed the initial versions of the USGv6 Profile and Testing Program. After multiple draft, public comment and revision cycles, version 1 of the USGv6 Profile was published in July 2008. The USGv6 Testing Program was developed in a similar fashion and became operational in November 2009. While the initial version of the profile and testing program defined the processes for evolving to future technical requirements and tests, to date the USGv6 program has chosen to favor stability of the specifications over yearly 'maintenance' updates. This approach allowed vendor products and the test program to mature to the point that we have multiple accredited test labs, a more complete set of standard test specifications and numerous products with USGv6 capabilities that have been tested for conformance and interoperability. This approach also facilitated the development of other initiatives and policies (e.g., Federal Acquisition Regulations and new OMB USG IPv6 Adoption Directives) that leverage the USGv6 program. Having gained 2+ years of practical experience in the use of the USGv6 program, and given the development of some new IETF specifications of particular significance to the USGv6 program, we feel it is time to develop version 2 of the USGv6 Profile. From the perspective of NIST there are several key issues that we would like to address in the next version of the profile, including: Generalize the scope and applicability of the profile. There is nothing inherently 'Governmental' about the profile or testing system, and we are aware of other user communities who have adopted aspects of the USGv6 program either by reference or duplication. We welcome broader use and adoption of the profile by groups outside the USG and solicit input from such organizations as to how we can structure version 2 of the profile to better suit their needs and/or actually produce a single joint profile. Improve the utility of the profile as a tool for specifying procurement requirements. The profile attempts to serve two audiences, purchasers and suppliers of IPv6 capabilities. Our experience to date is that the level of detail of version 1 of the profile might be a barrier to use by purchasers. We seek input from purchasers/users as to how to make the profile easier to use as a requirements check-list. Revise the concept / terms of 'device type' to make it clear that the profile addresses the definition of sets of capabilities, from which many product configurations can be instantiated and specified. Revise the profile testing sections to reflect the subsequent development of the Testing Program and its guidance documents. Restructure the Network Protection Device section to better accommodate the typical composition of products in this space. Review all IETF specifications cited in the profile to evaluate errata and revised specifications that might impact USGv6 requirements. Examples might include: Adopting the new IKEv2bis specification RFC 5996. Adopting the new OSPFbis specification RFC 5340. Revisiting the status of the various cryptographic algorithms cited in version 1. Review the status of NIST recommendations, in particular those capabilities marked SHOULD+ (S+) in version 1 of the profile, to evaluate which, if any, should advance to MUST (M). Review the state of IETF specification and the industry to see if any new capabilities/specifications should be added to the profile that were not in version 1. The issues noted above capture some of our broad observations from 2 years of experience in the development and operation of the USGv6 program. We assume that the broader community also has similar input and observations that should be considered before developing the first draft of version 2. Thus NIST plans to pursue the development of version 2 of the USGv6 profile as follows: Solicit community input and comment prior to the development of the 1st draft of USGV6-v2. Use the current profile and testing system as the basis / reference for your comments. Please submit comments using the provided spread sheet. Completed comment sheets should be emailed to usgv6-project@antd.nist.gov by COB June 10, 2011. NIST will review all received input and formulate a draft version 2 of the profile that will be distributed for public comment in September 2011. NIST will review and address all comments received and publish the revised USGv6-V2 Profile before the end of 2011. Note that if a second public comment period is warranted, we would conduct it such that it would not extend the target date above. If you have any questions or comments about this process, please send them to: usgv6-project@antd.nist.gov. We look forward to your input and participation. From jhw@apple.com Fri May 13 11:28:28 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 07720E07FA for ; Fri, 13 May 2011 11:28:28 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0utssovOxqy for ; Fri, 13 May 2011 11:28:27 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3E189E07F3 for ; Fri, 13 May 2011 11:28:26 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LL500KKECLXOWA0@mail-out.apple.com> for ipv6@ietf.org; Fri, 13 May 2011 11:28:18 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-38-4dcd78428509 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 relay15.apple.com (Apple SCV relay) with SMTP id BF.8E.18996.2487DCD4; Fri, 13 May 2011 11:28:18 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LL500KYOCN6PZ60@koseret.apple.com> for ipv6@ietf.org; Fri, 13 May 2011 11:28:18 -0700 (PDT) Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: james woodyatt X-Priority: 3 In-reply-to: <96DF83B6DC524A8EA916AA027F27FA4E@bessy> Date: Fri, 13 May 2011 11:28:18 -0700 Message-id: <15A0A392-B08A-4363-A496-C4D23C2C4C08@apple.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <96DF83B6DC524A8EA916AA027F27FA4E@bessy> To: 6MAN Working Group X-Mailer: Apple Mail (2.1227) X-Brightmail-Tracker: AAAAAA== 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, 13 May 2011 18:28:28 -0000 On May 13, 2011, at 09:28 , Timothy E. Enos wrote: > > Just as some environments may require the use of DHCPv6, some environments may not. Mobile hosts SHOULD implement DHCPv6 clients. I wouldn't oppose elevating the requirement further still to say that mobile hosts MUST implement DHCPv6 clients. -- james woodyatt member of technical staff, core os networking From suresh.krishnan@ericsson.com Fri May 13 11:30:53 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 1FF1BE0837 for ; Fri, 13 May 2011 11:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 LX-UyCwrHOUa for ; Fri, 13 May 2011 11:30:52 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id A0432E0835 for ; Fri, 13 May 2011 11:30:52 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p4DIUo0n017055; Fri, 13 May 2011 13:30:52 -0500 Received: from [142.133.10.107] (147.117.20.213) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.3.137.0; Fri, 13 May 2011 14:30:44 -0400 Message-ID: <4DCD78D7.1010207@ericsson.com> Date: Fri, 13 May 2011 14:30:47 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Thomas Narten Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> In-Reply-To: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.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: Fri, 13 May 2011 18:30:53 -0000 Hi Thomas, On 11-05-13 09:37 AM, Thomas Narten wrote: > Please respond yes or no. Given the WG's previous hesitation to having > DHCPv6 be a SHOULD, it is important that we get a clear indication of > whether or not the WG supports this change. Yes. I think that elevating DHCPv6 support to SHOULD is a good idea. Thanks Suresh From cb.list6@gmail.com Fri May 13 11:34:24 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 7DA95E084A for ; Fri, 13 May 2011 11:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ZTRNfb7LW9yk for ; Fri, 13 May 2011 11:34:24 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id AE764E0829 for ; Fri, 13 May 2011 11:34:23 -0700 (PDT) Received: by ewy19 with SMTP id 19so987028ewy.31 for ; Fri, 13 May 2011 11:34:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NuEzfTDD2M+BQUGLr6Jb1rULZYIcjvT9vLasmsTkFzU=; b=TZZ/U0Z0/kWH1IUv7WNo1R0o8s6qMyiSkCaPmvuDpD+SqktmMAae5ZIXagmxD+Wn4a J/ij+6BBW0QaHrrx5hwKNkaDYBqYSJ7M5nA0/B2KcFHBOiMIO+0s2WLIsunz6Rj5JvBX 0dK9O6aO6TjP8qfI8+twyjtKOIQxjfuIDLMnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bxBVFSjSr1PtNWx4mwRSgW7Hv+elCrVq04EFYe70mLEyRoFtkx4NvYE2njLOd2RniZ Iz/LxJJj0UpdwK1OLrXPUzVFAvtNnHY+WImIAjEFA5nuO2FgRpHgy/4Zgqw9q6qw9U18 9jLLiYShZH4mvvJS8YyR9scKgR9qAEMTULH3s= MIME-Version: 1.0 Received: by 10.14.22.13 with SMTP id s13mr735901ees.89.1305311662779; Fri, 13 May 2011 11:34:22 -0700 (PDT) Received: by 10.14.37.143 with HTTP; Fri, 13 May 2011 11:34:22 -0700 (PDT) Received: by 10.14.37.143 with HTTP; Fri, 13 May 2011 11:34:22 -0700 (PDT) In-Reply-To: <15A0A392-B08A-4363-A496-C4D23C2C4C08@apple.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <96DF83B6DC524A8EA916AA027F27FA4E@bessy> <15A0A392-B08A-4363-A496-C4D23C2C4C08@apple.com> Date: Fri, 13 May 2011 11:34:22 -0700 Message-ID: Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: Cameron Byrne To: james woodyatt Content-Type: multipart/alternative; boundary=90e6ba5bcaf1fb2d8304a32c8db6 Cc: 6MAN Working Group 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, 13 May 2011 18:34:24 -0000 --90e6ba5bcaf1fb2d8304a32c8db6 Content-Type: text/plain; charset=ISO-8859-1 On May 13, 2011 11:28 AM, "james woodyatt" wrote: > > On May 13, 2011, at 09:28 , Timothy E. Enos wrote: > > > > Just as some environments may require the use of DHCPv6, some environments may not. > > Mobile hosts SHOULD implement DHCPv6 clients. > > I wouldn't oppose elevating the requirement further still to say that mobile hosts MUST implement DHCPv6 clients. > > Why? Most mobile v6 nodes do not support it today. ... they use pco ie during session setup. Dhcpv6 is nice for LAN but generally not used in cellular networks . I do not believe there needs to be special wording for mobile Cb > -- > james woodyatt > member of technical staff, core os networking > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --90e6ba5bcaf1fb2d8304a32c8db6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On May 13, 2011 11:28 AM, "james woodyatt" <jhw@apple.com> wrote:
>
> On May 13, 2011, at 09:28 , Timothy E. Enos wrote:
> >
> > Just as some environments may require the use of DHCPv6, some env= ironments may not.
>
> Mobile hosts SHOULD implement DHCPv6 clients.
>
> I wouldn't oppose elevating the requirement further still to say t= hat mobile hosts MUST implement DHCPv6 clients.
>
>

Why?=A0 Most mobile v6 nodes do not support it today. ... they use pco i= e during session setup.

Dhcpv6 is nice for LAN but generally not used in cellular networks .

I do not believe there needs to be special wording for mobile

Cb
> --
> james woodyatt <jhw@apple.com&= gt;
> member of technical staff, core os networking
>
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--90e6ba5bcaf1fb2d8304a32c8db6-- From randy@psg.com Fri May 13 11:39:33 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 670D0E0856 for ; Fri, 13 May 2011 11:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dWdoRE79rWqS for ; Fri, 13 May 2011 11:39:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id D0EB6E0851 for ; Fri, 13 May 2011 11:39:32 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.home.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QKxFd-000B7X-CT; Fri, 13 May 2011 18:38:13 +0000 Date: Fri, 13 May 2011 20:38:12 +0200 Message-ID: From: Randy Bush To: Thomas Narten Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD In-Reply-To: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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, 13 May 2011 18:39:33 -0000 > Per a previous thread, there are indications that the WG may now be > willing to recommend that DHCPv6 be a SHOULD for all hosts. fwiw, there are large broadband providers that provision using dhcpv4 today. randy From wbeebee@cisco.com Fri May 13 11:43: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 BDB6EE0862 for ; Fri, 13 May 2011 11:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 T6DqrZfsgqEK for ; Fri, 13 May 2011 11:43:39 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA0EE072D for ; Fri, 13 May 2011 11:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=2817; q=dns/txt; s=iport; t=1305312214; x=1306521814; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=iQD9wb0wVMGy2APNzmE2qBOcHDh+97nIPB4HKWujrH0=; b=ccArV/TU/9MDRpA+oIodMe1IziE7Y/HQSobrSkAeLB0Bj1svcoJwWPpm a7OWIPoYHYrC8uMF37X8TNa0HvwoFEibFd4XIlVT2lmgd+vpylUMSMzzv zjuY27DnotIWLlL2Wg9SsMvYdQKKp9V33/REoGa4DS0+rtjb3RUpUVDsw o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMGABd7zU2tJXG9/2dsb2JhbACCZIY7nAZjAneIcJ51ngGGFQSQBoQ4hmmDbQ X-IronPort-AV: E=Sophos;i="4.64,365,1301875200"; d="scan'208,217";a="315195121" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-3.cisco.com with ESMTP; 13 May 2011 18:43:33 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4DIhXEg022877; Fri, 13 May 2011 18:43:33 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 13:43:33 -0500 Received: from 161.44.175.134 ([161.44.175.134]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 May 2011 18:43:33 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Fri, 13 May 2011 14:43:30 -0400 Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: Wes Beebee To: Cameron Byrne , james woodyatt Message-ID: Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AcwRnac5w5Xz8+FqCk6P5D069MQrlQ== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3388142610_1328840" X-OriginalArrivalTime: 13 May 2011 18:43:33.0112 (UTC) FILETIME=[A9144F80:01CC119D] Cc: 6MAN Working Group 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, 13 May 2011 18:43:40 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3388142610_1328840 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable > I do not believe there needs to be special wording for mobile Or for any other specific deployment for that matter. The reason I mentioned cable is because many popular operating system-based hosts as wel= l as specific devices have to be able to operate in a cable environment =AD and the operational reality is that it is a MUST for all of them. However, since there are other, closed, controlled environments where DHCPv6 may not be necessary, SHOULD is the perfect level to cover all of the deployment environments. SHOULD means that you have to follow it unless you have a good case why not (see RFC 2119 below): 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course - Wes --B_3388142610_1328840 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD > I do not believe there needs to be special wording for mobile

Or for any other specific deployment for that matter.  The reason I me= ntioned cable is because many popular operating system-based hosts as well a= s specific devices have to be able to operate in a cable environment –= and the operational reality is that it is a MUST for all of them.  How= ever, since there are other, closed, controlled environments where DHCPv6 ma= y not be necessary, SHOULD is the perfect level to cover all of the deployme= nt environments.  SHOULD means that you have to follow it unless you ha= ve a good case why not (see RFC 2119 below):

3. SHOULD   This word, or the adjective "= RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ign= ore a
   particular item, but the full implications must be unders= tood and
   carefully weighed before choosing a different course

- Wes --B_3388142610_1328840-- From jhw@apple.com Fri May 13 11:56: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 14A2AE0874 for ; Fri, 13 May 2011 11:56:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUC1aFvYAgN2 for ; Fri, 13 May 2011 11:56:36 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id D1D10E0872 for ; Fri, 13 May 2011 11:56:36 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LL500K3WDX4O241@mail-out.apple.com> for ipv6@ietf.org; Fri, 13 May 2011 11:56:28 -0700 (PDT) X-AuditID: 11807137-b7cd4ae000003108-77-4dcd7edce370 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 75.45.12552.CDE7DCD4; Fri, 13 May 2011 11:56:28 -0700 (PDT) Received: from [17.193.13.64] (unknown [17.193.13.64]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LL500LTXDY4P540@cardamom.apple.com> for ipv6@ietf.org; Fri, 13 May 2011 11:56:28 -0700 (PDT) Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: james woodyatt In-reply-to: Date: Fri, 13 May 2011 11:56:27 -0700 Message-id: References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <96DF83B6DC524A8EA916AA027F27FA4E@bessy> <15A0A392-B08A-4363-A496-C4D23C2C4C08@apple.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1227) X-Brightmail-Tracker: AAAAAA== Cc: 6MAN Working Group 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, 13 May 2011 18:56:40 -0000 On May 13, 2011, at 11:34 , Cameron Byrne wrote: > On May 13, 2011 11:28 AM, "james woodyatt" wrote: > > > > Mobile hosts SHOULD implement DHCPv6 clients. > > I wouldn't oppose elevating the requirement further still to say that mobile hosts MUST implement DHCPv6 clients. > > Why? Most mobile v6 nodes do not support it today. [...] I was thinking about RFC 3775, section 11.5.2, which says: As described in Section 4, in order to form a new care-of address, a mobile node MAY use either stateless [13] or stateful (e.g., DHCPv6 [29]) Address Autoconfiguration. -- james woodyatt member of technical staff, core os networking From Basavaraj.Patil@nokia.com Fri May 13 12:01: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 3D68BE0887 for ; Fri, 13 May 2011 12:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 gXFj8Tv07MuA for ; Fri, 13 May 2011 12:01:31 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id B7EF2E088B for ; Fri, 13 May 2011 12:00:46 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4DJ0gFv010511; Fri, 13 May 2011 22:00:42 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 22:00:41 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 13 May 2011 21:00:40 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.125]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0289.008; Fri, 13 May 2011 21:00:40 +0200 From: To: , Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AQHMEXM/ZfKIkYxUoEGBNHFgX3zbhZSK8t8F////wgCAAAGyAIAABiyA//+tXAA= Date: Fri, 13 May 2011 19:00:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [172.19.59.152] Content-Type: text/plain; charset="us-ascii" Content-ID: <4AA4C9C1BF4C944CA24905479E404806@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2011 19:00:41.0842 (UTC) FILETIME=[0E400D20:01CC11A0] X-Nokia-AV: Clean 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, 13 May 2011 19:01:32 -0000 On 5/13/11 1:56 PM, "ext james woodyatt" wrote: >On May 13, 2011, at 11:34 , Cameron Byrne wrote: >> On May 13, 2011 11:28 AM, "james woodyatt" wrote: >> > >> > Mobile hosts SHOULD implement DHCPv6 clients. >> > I wouldn't oppose elevating the requirement further still to say that >>mobile hosts MUST implement DHCPv6 clients. >>=20 >> Why? Most mobile v6 nodes do not support it today. [...] > >I was thinking about RFC 3775, section 11.5.2, which says: > > As described in Section 4, in order to form a new care-of address, a > mobile node MAY use either stateless [13] or stateful (e.g., DHCPv6 > [29]) Address Autoconfiguration. How a MIP6 (or DSMIP6) MN configures the IPv6 CoA has no bearing on the present discussion. I do agree with Cameron that a MUST for mobile devices is a bad idea. -Raj > > >-- >james woodyatt >member of technical staff, core os networking > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From behcetsarikaya@yahoo.com Fri May 13 12:59: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 CF2BCE087A for ; Fri, 13 May 2011 12:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599] 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 ostkDd9qlDs9 for ; Fri, 13 May 2011 12:59:35 -0700 (PDT) Received: from nm6.bullet.mail.sp2.yahoo.com (nm6.bullet.mail.sp2.yahoo.com [98.139.91.76]) by ietfa.amsl.com (Postfix) with SMTP id 57558E0824 for ; Fri, 13 May 2011 12:59:35 -0700 (PDT) Received: from [98.139.91.70] by nm6.bullet.mail.sp2.yahoo.com with NNFMP; 13 May 2011 19:59:31 -0000 Received: from [98.139.91.43] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 13 May 2011 19:59:31 -0000 Received: from [127.0.0.1] by omp1043.mail.sp2.yahoo.com with NNFMP; 13 May 2011 19:59:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 505009.84611.bm@omp1043.mail.sp2.yahoo.com Received: (qmail 47195 invoked by uid 60001); 13 May 2011 19:59:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1305316771; bh=8dOqARJvrwY1A16SQtywk02NJmBEgiB7a+m+xMrgxNI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aqggtUpyown6HaREvuV9xI82XmHMWkRpcEEr62rTDd81jARgFM043FDW9fjpOy65t055/o+fDmgfBfopgobwJQefjVQSW2H39VJBx9scOqDnS+gbxQDuxG2QG8dfX32vIhkDRgAXubPN4KSOseQJAJp/o59FbmzTH2jJ61O1pZ4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YFtT4QdEUOOkqVBLyXppCTeXfQ9bW+NoN+GlXQxlo4zbaWmMgVwFUg4ZRkosZFadiCH9A/v/m0H1uqmxfGoHXG+Wcp6AFZp8fM4Irqeqg7/RkPxNDRnDwpLU+jETfycODTAd7fyMmFXvH89/JiSSJGmmwiNiClgJOl8W89LkkAQ=; Message-ID: <100587.45242.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: qQ9nYqwVM1k01IaSUNBzT3ekOPSnvbmjV93rt1OKZMo.CB2 5.YIolbNeYuXPFeHYPPqJp9dtO7edtpcP386DbIoBQG6C4Nw2gR8A9p3pN.G basoptPozO5pFUbg5tiabyHvloIGuOiLFZ9JXlCYRwgR3tmozJbNB4vZEB1S Ibga6uehBcvQnzfKP3tEFZFEIMthGCo1J9kCTz2zhwCADKDFEIGDAFM0jM5E kqqkBqphA5dwAXDkG8RZc9PGyvunhjJ1nh2l1zHKrXTCnHB4pShtu4ORM06x _azeVm4laVI4kTWyhRLL8r.SA43PEZnPXZdr44PulqDqaUXEJztGQ2BL0zHb u8e6Z7wePZP1VQHNMMpsFB8QGil6SEVpx6E6KgK7mMnQBdOsyv.RnOAOk5pZ lOB03SLM_MWZaIg-- Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Fri, 13 May 2011 12:59:30 PDT X-Mailer: YahooMailWebService/0.8.111.303096 References: Date: Fri, 13 May 2011 12:59:30 -0700 (PDT) From: Behcet Sarikaya Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD To: "Basavaraj.Patil@nokia.com" , "jhw@apple.com" , "cb.list6@gmail.com" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 13 May 2011 13:02:28 -0700 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 19:59:35 -0000 =0A=0A> =0A> =0A> On 5/13/11 1:56 PM, "ext james woodyatt" = wrote:=0A> =0A>> On May 13, 2011, at 11:34 , Cameron Byrne wrote:=0A>>> On= May 13, 2011 11:28 AM, "james woodyatt" =0A> wrote:=0A>>> = >=0A>>> > Mobile hosts SHOULD implement DHCPv6 clients.=0A>>> > I wouldn= 't oppose elevating the requirement further still to =0A> say that=0A>>> mo= bile hosts MUST implement DHCPv6 clients.=0A>>> =0A>>> Why?=A0 Most mobile= v6 nodes do not support it today. [...]=0A>> =0A>> I was thinking about RF= C 3775, section 11.5.2, which says:=0A>> =0A>> =A0 =A0 As described in Sect= ion 4, in order to form a new care-of address, a=0A>> =A0 =A0 mobile node M= AY use either stateless [13] or stateful (e.g., DHCPv6=0A>> =A0 =A0 [29]) A= ddress Autoconfiguration.=0A> =0A> How a MIP6 (or DSMIP6) MN configures the= IPv6 CoA has no bearing on the=0A> present discussion.=0A> I do agree with= Cameron that a MUST for mobile devices is a bad idea.=0A=0AI think it woul= d be much cheaper to implement DHCPv6 client on a mobile than SLAAC code.= =0A=0A--b=0A From edward.jankiewicz@sri.com Fri May 13 13:13: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 5F824E06C3 for ; Fri, 13 May 2011 13:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 G-I8VC7ZF9m6 for ; Fri, 13 May 2011 13:13:49 -0700 (PDT) Received: from mail1.sri.com (mail.SRI.COM [128.18.30.17]) by ietfa.amsl.com (Postfix) with ESMTP id E9E0EE069E for ; Fri, 13 May 2011 13:13:49 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [128.18.208.10] ([unknown] [128.18.70.25]) by mail.sri.com (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPS id <0LL500FIOHIZZP30@mail.sri.com> for ipv6@ietf.org; Fri, 13 May 2011 13:13:49 -0700 (PDT) Message-id: <4DCD9110.10000@sri.com> Date: Fri, 13 May 2011 16:14:08 -0400 From: Ed Jankiewicz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 To: Thomas Narten Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <4462F666-D0FD-45C1-AE71-0CD70580C110@gmail.com> <201105131602.p4DG2L3L010708@cichlid.raleigh.ibm.com> In-reply-to: Cc: Bob Hinden , ipv6@ietf.org, Ralph Droms 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, 13 May 2011 20:13:50 -0000 I support the idea of making DHCPv6 a SHOULD, and like the text revision proposed by Bob as amended by Ralph. As to the clarification of what to do in the event of inconsistent information when both methods are used, I agree that RFC 4862 covers it. If pushed, citing that RFC would be better than incorporating text. The comment from Tim that the DHCPv6 man not be of use in SOHO deployments, I think SHOULD still leaves enough wiggle room for a variety of implementations with different feature sets. On 5/13/2011 12:22 PM, Ralph Droms wrote: > On May 13, 2011, at 12:02 PM 5/13/11, Thomas Narten wrote: > >> Bob, >> >> Bob Hinden writes: >> >>> While I support changing the requirement to a SHOULD, I would prefer >>> the text to be something like: >>> DHCPv6 can be used to obtain and >>> configure addresses. In general, a network may provide for the >>> configuration of addresses through Router Advertisements, >>> DHCPv6 or both. There will be a wide range of IPv6 deployment models >>> and differences in address assignment requirements. Consequently all hosts >>> SHOULD implement address configuration via DHCP. >>> It's not just about what some operators may or may not do. For >>> example enterprises, governments, etc. will also have specific >>> requirements. >> I like this text better than what I proposed as well. > Here's my contribution, trying to make an explicit link between the last two sentences: > > DHCPv6 can be used to obtain and > configure addresses. In general, a network may provide for the > configuration of addresses through Router Advertisements, > DHCPv6 or both. There will be a wide range of IPv6 deployment > models and differences in address assignment requirements, > some of which may require DHCPv6 for address assignment. > Consequently all hosts SHOULD implement address configuration > via DHCPv6. > >> Thanks, >> Thomas >> -------------------------------------------------------------------- >> 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 > -------------------------------------------------------------------- -- Edward J Jankiewicz, Senior Technical Advisor ESG/ISD - Center for Navigation and Survivability Systems SRI International, Inc. edward.jankiewicz@sri.com Direct: 443-502-5815 Google Voice: 908-718-1335 From albert.e.manfredi@boeing.com Fri May 13 13:25:47 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 BB71AE0798 for ; Fri, 13 May 2011 13:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 JvWmyKxt1FSF for ; Fri, 13 May 2011 13:25:47 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 39A60E06C8 for ; Fri, 13 May 2011 13:25:47 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4DKPdqY007265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 May 2011 13:25:40 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p4DKPcMS028743; Fri, 13 May 2011 15:25:39 -0500 (CDT) Received: from XCH-MWHT-01.mw.nos.boeing.com (xch-mwht-01.mw.nos.boeing.com [134.57.113.35]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4DKPcwN028706 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 13 May 2011 15:25:38 -0500 (CDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-01.mw.nos.boeing.com ([134.57.113.35]) with mapi; Fri, 13 May 2011 15:25:38 -0500 From: "Manfredi, Albert E" To: Ed Jankiewicz Date: Fri, 13 May 2011 15:25:36 -0500 Subject: RE: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AcwRqlMOOXddsDNERam6BZNa8DrfegAAQ6ZQ Message-ID: References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com><4462F666-D 0FD-45C1-AE71-0CD70580C110@gmail.com><201105131602.p4DG2L3L010708@cichlid.r aleigh.ibm.com> <4DCD9110.10000@sri.com> In-Reply-To: <4DCD9110.10000@sri.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 13 May 2011 20:25:47 -0000 Ed Jankiewicz wrote: > The comment from Tim that the DHCPv6 man not be of use in SOHO > deployments, I think SHOULD still leaves enough wiggle room for a > variety of implementations with different feature sets. I support SHOULD for DHCPv6 as well. But responding to the above, purely parenthetically, would DOCSIS be out of= the question in a SOHO network? If not, and I think not, then we have been= hearing that cable networks do use DHCP. So it would become mandatory is S= OHO nets that depend on cable broadband. Bert From alh-ietf@tndh.net Fri May 13 13:50:47 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 4E553E085C for ; Fri, 13 May 2011 13:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.045 X-Spam-Level: * X-Spam-Status: No, score=1.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 PaIQMGBJ2ZRc for ; Fri, 13 May 2011 13:50:46 -0700 (PDT) Received: from tndh.net (unknown [50.46.43.186]) by ietfa.amsl.com (Postfix) with ESMTP id BB76AE085B for ; Fri, 13 May 2011 13:50:46 -0700 (PDT) X-AuthUser: alh-ietf@tndh.net Received: from ahainW7 ([192.168.112.18]:17550) by tndh.net with [XMail 1.27 ESMTP Server] id for from ; Fri, 13 May 2011 13:50:43 -0700 From: "Tony Hain" To: "'Ralph Droms'" , "'Thomas Narten'" References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <4462F666-D0FD-45C1-AE71-0CD70580C110@gmail.com> <201105131602.p4DG2L3L010708@cichlid.raleigh.ibm.com> In-Reply-To: Subject: RE: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Date: Fri, 13 May 2011 13:50:40 -0700 Message-ID: <043301cc11af$6d4996b0$47dcc410$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwRigq5rfZauEgiTsCw3xaPt1KKsQAJVjLA Content-Language: en-us Cc: 'Bob Hinden' , 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, 13 May 2011 20:50:47 -0000 I agree with Ralph's text. > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Ralph Droms > Sent: Friday, May 13, 2011 9:23 AM > To: Thomas Narten > Cc: ipv6@ietf.org; Bob Hinden; Ralph Droms > Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD > > > On May 13, 2011, at 12:02 PM 5/13/11, Thomas Narten wrote: > > > Bob, > > > > Bob Hinden writes: > > > >> While I support changing the requirement to a SHOULD, I would prefer > >> the text to be something like: > > > >> DHCPv6 can be used to obtain > and > >> configure addresses. In general, a network may provide for the > >> configuration of addresses through Router Advertisements, > >> DHCPv6 or both. There will be a wide range of IPv6 deployment > models > >> and differences in address assignment requirements. > Consequently all hosts > >> SHOULD implement address configuration via DHCP. > > > >> It's not just about what some operators may or may not do. For > >> example enterprises, governments, etc. will also have specific > >> requirements. > > > > I like this text better than what I proposed as well. > > Here's my contribution, trying to make an explicit link between the > last two sentences: > > DHCPv6 can be used to obtain and > configure addresses. In general, a network may provide for the > configuration of addresses through Router Advertisements, > DHCPv6 or both. There will be a wide range of IPv6 deployment > models and differences in address assignment requirements, > some of which may require DHCPv6 for address assignment. > Consequently all hosts SHOULD implement address configuration > via DHCPv6. > > > > > Thanks, > > Thomas > > -------------------------------------------------------------------- > > 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 rja.lists@gmail.com Fri May 13 16:12: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 68A8CE08E1 for ; Fri, 13 May 2011 16:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 4exsMf+SeL3D for ; Fri, 13 May 2011 16:12:54 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B9F15E07E9 for ; Fri, 13 May 2011 16:12:54 -0700 (PDT) Received: by qyk29 with SMTP id 29so628714qyk.10 for ; Fri, 13 May 2011 16:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=3B9g8KYI2YXxuTrh6shL3RYGni5FoHRyFr0fi99z2k4=; b=Lim+IQoDMi0hVRNu1yNJvk347We269wQ4cLbOY1H0CVF59Lcyjyzdaw2aQ6MW579In PgZzufbu+/DMCZTTY+bcLaqGiTeZsBxwJaH/mPIW6WBCOU1XoTogyvJi1Cdk3K8M5AMA /ksY8+qzRNqQmsS5U1iK5qDLU3vpcMvL4zG9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=PYYrHC8W26mBHyfwF2RmYIHHR2kgkK8BDXBWIYwZFrLEM8L6tAEAjQZk3zuykzWsEw u6bWcwMPUNGi6nzY9SdxRiqwwkP3mhcdHYFmaDNTIPZ9yYHimu/2hBAbZxSf0oN0GLBm G3DYUpjSzHjIP7pPz3XdCZ+3rKHfewIQ6s/3Q= Received: by 10.224.113.81 with SMTP id z17mr1622399qap.158.1305328374134; Fri, 13 May 2011 16:12:54 -0700 (PDT) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id s16sm1649934qco.13.2011.05.13.16.12.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2011 16:12:53 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: moving DHCPv6 to SHOULD Date: Fri, 13 May 2011 19:12:51 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 13 May 2011 23:12:55 -0000 I support moving DHCPv6 to SHOULD instead of MAY. I like Bob Hinden's proposed edit because it more neutrally describes the wide range of deployment environments where DHCPv6 might be a practical requirement, but I'm flexible on the wording. Ran From sthaug@nethelp.no Fri May 13 16:21:59 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 289DFE082C for ; Fri, 13 May 2011 16:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 18uJ3vacma7Q for ; Fri, 13 May 2011 16:21:58 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 0C51CE0811 for ; Fri, 13 May 2011 16:21:54 -0700 (PDT) Received: (qmail 59921 invoked from network); 13 May 2011 23:21:52 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 13 May 2011 23:21:52 -0000 Date: Sat, 14 May 2011 01:21:52 +0200 (CEST) Message-Id: <20110514.012152.41686540.sthaug@nethelp.no> To: swmike@swm.pp.se Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: sthaug@nethelp.no In-Reply-To: References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) 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: Fri, 13 May 2011 23:21:59 -0000 > > Per a previous thread, there are indications that the WG may now be > > willing to recommend that DHCPv6 be a SHOULD for all hosts. This is > > based on the following rationale: > > I support moving it to SHOULD. Agreed. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From brian@innovationslab.net Fri May 13 16:32:14 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 0A71DE07B6 for ; Fri, 13 May 2011 16:32:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzhLy1nFKi79 for ; Fri, 13 May 2011 16:32:13 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 22F96E0749 for ; Fri, 13 May 2011 16:32:13 -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 B3C9E8815E for ; Fri, 13 May 2011 16:25:53 -0700 (PDT) Received: from clemson.local (c-76-100-105-215.hsd1.md.comcast.net [76.100.105.215]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 2193B130002 for ; Fri, 13 May 2011 16:32:11 -0700 (PDT) Message-ID: <4DCDBF77.90604@innovationslab.net> Date: Fri, 13 May 2011 19:32:07 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <20110514.012152.41686540.sthaug@nethelp.no> In-Reply-To: <20110514.012152.41686540.sthaug@nethelp.no> X-Enigmail-Version: 1.1.1 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: Fri, 13 May 2011 23:32:14 -0000 All, The chairs have determined that there is a strong consensus to elevate DHCPv6 to SHOULD support in the node requirements document. Since this is the last open issue with this document, the chairs will begin the advancement process when a new version is published. Regards, Brian & Bob On 5/13/11 7:21 PM, sthaug@nethelp.no wrote: >>> Per a previous thread, there are indications that the WG may now be >>> willing to recommend that DHCPv6 be a SHOULD for all hosts. This is >>> based on the following rationale: >> >> I support moving it to SHOULD. > > Agreed. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From ipng@69706e6720323030352d30312d31340a.nosense.org Fri May 13 16:54: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 05E98E082D for ; Fri, 13 May 2011 16:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 6KCmLTTlpV2q for ; Fri, 13 May 2011 16:54:40 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 525CBE0694 for ; Fri, 13 May 2011 16:54:40 -0700 (PDT) Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QL2Bo-00013P-JD; Sat, 14 May 2011 09:24:36 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id D251C3B338; Sat, 14 May 2011 09:24:33 +0930 (CST) Date: Sat, 14 May 2011 09:24:33 +0930 From: Mark Smith To: "Manfredi, Albert E" Subject: Re: Short 6MAN WG Last Call: Message-ID: <20110514092433.30dff4ef@opy.nosense.org> In-Reply-To: References: <05DD243A-277C-4 777-91D0-CB9E609E733A@employees.org> <201105061748.p46HmJu8015684@cichlid.ra leigh.ibm.com> <201105121323.p4CDNKUM006703@cichlid.raleigh.ibm.com> <20110513073729.52a39f70@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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: 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, 13 May 2011 23:54:41 -0000 Hi Bert, On Thu, 12 May 2011 17:22:05 -0500 "Manfredi, Albert E" wrote: > Mark Smith wrote: > > > I think it would be reasonable to make DHCP a SHOULD, however > > I've thought that one of the reasons SLAAC exists is to provide > > simpler and lighter weight address configuration method for resource > > constrained end-nodes such as embedded ones. So perhaps it could be > > worth mentioning that an example of an exception to the SHOULD would be > > those types of end-nodes. > > More generally, I'd say SLAAC exists because with IPv6 it's possible to assign globally unique IP addresses to hosts, without risk of collisions, without having to have the network specify all of the 128 bits. > > But in situations where the address provided to a host must be completely predictable, SLAAC won't work. > > I don't think that resource-constrained need to be a significant criterion? > I'd thought that SLAAC was created instead of just making an IPv6 equivalent of DHCPv4 and leaving that as a single address configuration mechanism was because it required less maintained state and processing. Less maintained state and processing would best suit low CPU powered and memory devices, which is why I suggested "loosening" the SHOULD for DHCPv6 a bit for those devices. SLAAC is of course convenient in other situations too. Regards, Mark. From john_brzozowski@cable.comcast.com Sun May 15 05:11: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 4E8B7E06CF for ; Sun, 15 May 2011 05:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.463 X-Spam-Level: X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 aDUBgVNV1nYg for ; Sun, 15 May 2011 05:11:08 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 736ACE06C7 for ; Sun, 15 May 2011 05:11:08 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.123177716; Sun, 15 May 2011 08:11:05 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0289.001; Sun, 15 May 2011 08:11:04 -0400 From: "Brzozowski, John" To: Thomas Narten , "ipv6@ietf.org" Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AQHMEXNYf+V3/K1jwk2ucgUWFKlw4pSNz2oA Date: Sun, 15 May 2011 12:11:03 +0000 Message-ID: In-Reply-To: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [98.225.180.189] Content-Type: text/plain; charset="us-ascii" Content-ID: <8A8AA8825E633347A4693F94252B9519@cable.comcast.com> Content-Transfer-Encoding: quoted-printable 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: Sun, 15 May 2011 12:11:09 -0000 Thomas, I am in favor of the new text. You may want to be specific and refer to stateful DHCPv6. Speaking as an operator, for WAN interface provisioning stateful DHCPv6 is a requirement. Stateless is not supported at all at this time. Thanks, John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 5/13/11 9:37 AM, "Thomas Narten" wrote: >Per a previous thread, there are indications that the WG may now be >willing to recommend that DHCPv6 be a SHOULD for all hosts. This is >based on the following rationale: > >Thomas Narten writes: > >> I personally would support having DHCP be a SHOULD rather than a >> MAY. The justification in my mind is that if you want the network >> operator to have the choice of whether they want to use Stateless >> addrconf OR DHCP, they only have that choice of devices widely >> implement both. > >This was supported by some others, particularly now that it is clear >there are more implementations of DHCPv6, e.g.: > >Bob Hinden writes: > >> While my personal view is that DHCPv6 won't be used for host >> configuration in cable/DSL deployments (except for provisioning the >> prefix to the home router), it appears that DHCPv6 is being widely >> implemented in host OS's because it is needed some environments. >> There are enough variations in deployment models that a host >> developer will need to support both. > >> Based on this, I think a SHOULD is OK. > >Let me propose the following change be made to the node requirements >document: > >OLD/Current: > > DHCP can be used to obtain and configure addresses. In general, a > network may provide for the configuration of addresses through Router > Advertisements, DHCP or both. At the present time, the configuration > of addresses via stateless autoconfiguration is more widely > implemented in hosts than address configuration via DHCP. However, > some environments may require the use of DHCP and may not support the > configuration of addresses via RAs. Implementations should be aware > of what operating environment their devices will be deployed. Hosts > MAY implement address configuration via DHCP. > >New: > > DHCPv6 can be used to obtain and > configure addresses. In general, a network may provide for the > configuration of addresses through Router Advertisements, > DHCPv6 or both. Some operators have indicated that they do > not intend to support stateless address autoconfiguration on > their networks and will require all address assignments be > made through DHCPv6. On such networks, devices that support > only stateless address autoconfiguration will be unable to > automatically configure addresses. Consequently all hosts > SHOULD implement address configuration via DHCP. > > >Is this acceptable? > >Please respond yes or no. Given the WG's previous hesitation to having >DHCPv6 be a SHOULD, it is important that we get a clear indication of >whether or not the WG supports this change. > >Thomas >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From john_brzozowski@cable.comcast.com Sun May 15 05:15: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 6A7F4E0710 for ; Sun, 15 May 2011 05:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.435 X-Spam-Level: X-Spam-Status: No, score=-101.435 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] 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 ArKUMOGdv7AV for ; Sun, 15 May 2011 05:15:44 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id A1FD4E067B for ; Sun, 15 May 2011 05:15:44 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.38474100; Sun, 15 May 2011 06:19:51 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0289.001; Sun, 15 May 2011 08:15:39 -0400 From: "Brzozowski, John" To: Bob Hinden , Thomas Narten Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AQHMEXNYf+V3/K1jwk2ucgUWFKlw4pSLLJsAgAKkFIA= Date: Sun, 15 May 2011 12:15:37 +0000 Message-ID: In-Reply-To: <4462F666-D0FD-45C1-AE71-0CD70580C110@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <61CC598D3F4AB140A9EC632B9256A511@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 15 May 2011 12:15:45 -0000 Interesting point Bob raises. Thomas, Is the intention for the new text to relax the requirement for auto-configuration? The new DHCPv6 text should be in addition to support for stateless auto-configuration to ensure other deployment models are supported. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 5/13/11 11:55 AM, "Bob Hinden" wrote: >Thomas, > >On May 13, 2011, at 6:37 AM, Thomas Narten wrote: > >> Per a previous thread, there are indications that the WG may now be >> willing to recommend that DHCPv6 be a SHOULD for all hosts. This is >> based on the following rationale: >>=20 >> Thomas Narten writes: >>=20 >>> I personally would support having DHCP be a SHOULD rather than a >>> MAY. The justification in my mind is that if you want the network >>> operator to have the choice of whether they want to use Stateless >>> addrconf OR DHCP, they only have that choice of devices widely >>> implement both. >>=20 >> This was supported by some others, particularly now that it is clear >> there are more implementations of DHCPv6, e.g.: >>=20 >> Bob Hinden writes: >>=20 >>> While my personal view is that DHCPv6 won't be used for host >>> configuration in cable/DSL deployments (except for provisioning the >>> prefix to the home router), it appears that DHCPv6 is being widely >>> implemented in host OS's because it is needed some environments. >>> There are enough variations in deployment models that a host >>> developer will need to support both. >>=20 >>> Based on this, I think a SHOULD is OK. >>=20 >> Let me propose the following change be made to the node requirements >> document: >>=20 >> OLD/Current: >>=20 >> DHCP can be used to obtain and configure addresses. In general, a >> network may provide for the configuration of addresses through Router >> Advertisements, DHCP or both. At the present time, the configuration >> of addresses via stateless autoconfiguration is more widely >> implemented in hosts than address configuration via DHCP. However, >> some environments may require the use of DHCP and may not support the >> configuration of addresses via RAs. Implementations should be aware >> of what operating environment their devices will be deployed. Hosts >> MAY implement address configuration via DHCP. >>=20 >> New: >>=20 >> DHCPv6 can be used to obtain and >> configure addresses. In general, a network may provide for the >> configuration of addresses through Router Advertisements, >> DHCPv6 or both. Some operators have indicated that they do >> not intend to support stateless address autoconfiguration on >> their networks and will require all address assignments be >> made through DHCPv6. On such networks, devices that support >> only stateless address autoconfiguration will be unable to >> automatically configure addresses. Consequently all hosts >> SHOULD implement address configuration via DHCP. >>=20 >>=20 >> Is this acceptable? >>=20 >> Please respond yes or no. Given the WG's previous hesitation to having >> DHCPv6 be a SHOULD, it is important that we get a clear indication of >> whether or not the WG supports this change. > >While I support changing the requirement to a SHOULD, I would prefer the >text to be something like: > > DHCPv6 can be used to obtain and > configure addresses. In general, a network may provide for the > configuration of addresses through Router Advertisements, > DHCPv6 or both. There will be a wide range of IPv6 deployment models > and differences in address assignment requirements. Consequently >all hosts > SHOULD implement address configuration via DHCP. > >It's not just about what some operators may or may not do. For example >enterprises, governments, etc. will also have specific requirements. > >Bob > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From john_brzozowski@cable.comcast.com Sun May 15 05:34:03 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 86A50E0689 for ; Sun, 15 May 2011 05:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.585 X-Spam-Level: X-Spam-Status: No, score=-101.585 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] 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 qbktzoJtyhnB for ; Sun, 15 May 2011 05:34:02 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 98E47E068C for ; Sun, 15 May 2011 05:34:01 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.38474785; Sun, 15 May 2011 06:38:07 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Sun, 15 May 2011 08:33:55 -0400 From: "Brzozowski, John" To: Ralph Droms , John Loughney Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AQHMEvxaf+V3/K1jwk2ucgUWFKlw4g== Date: Sun, 15 May 2011 12:33:54 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <0F4ECCFDBACABF4E9AD629055D18F535@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "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, 15 May 2011 12:34:03 -0000 Ralph, Thomas, John, The attributes that come to mind are those that are DNS related via RFC6106. In theory I suppose what John mentioned could be an issue, however, in a broadband DOCSIS environment we only support stateful DHCPv6 for provisioning today as such I do not anticipate seeing these sort of issues in this scenario. I could sooner see the issue John raises occurring in an enterprise or within a home network, especially the latter. Regarding the latter, we have seen home router implementations that issue link local addresses and global unicast addresses simultaneously via RFC6106 for DNS server addresses. This has since been corrected. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 5/13/11 12:26 PM, "Ralph Droms" wrote: >John... >On May 13, 2011, at 12:19 PM 5/13/11, wrote: > >> Hi all, >>=20 >> In general, I support Thomas' text, but I still think some >>clarification is needed: >>=20 >>> New: >>>=20 >>> DHCPv6 can be used to obtain and >>> configure addresses. In general, a network may provide for the >>> configuration of addresses through Router Advertisements, >>> DHCPv6 or both. Some operators have indicated that they do >>> not intend to support stateless address autoconfiguration on >>> their networks and will require all address assignments be >>> made through DHCPv6. On such networks, devices that support >>> only stateless address autoconfiguration will be unable to >>> automatically configure addresses. Consequently all hosts >>> SHOULD implement address configuration via DHCP. >>=20 >> Should we give some guidance on what to do if both mechanisms are >>available >> on a network, the methods give contradictory information? I don't think >>it is >> enough to say that both SHOULD be supported, without giving additional >> clarification on what it means when both are supported. > >I think the IETF has been pretty good about keeping the information from >the two sources independent. Regarding address assignment specifically, >what contradictory information might be provided? I can imagine a node >might get one address from SLAAC and another from DHCPv6, but that's an >acceptable configuration. DHCPv6 doesn't provide prefix information, so >no conflicts there. I don't think there's an issue if DHCPv6 assigns an >address that's not in a prefix advertised in an RA. > >- Ralph > >>=20 >> John >>=20 >> -------------------------------------------------------------------- >> 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 john_brzozowski@cable.comcast.com Sun May 15 06:14: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 3125AE067E for ; Sun, 15 May 2011 06:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.999 X-Spam-Level: X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=3.464, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 88YPW3xh3CMq for ; Sun, 15 May 2011 06:14:22 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 85B64E0651 for ; Sun, 15 May 2011 06:14:22 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.123180006; Sun, 15 May 2011 09:14:17 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Sun, 15 May 2011 09:14:17 -0400 From: "Brzozowski, John" To: Alexandru Petrescu , "ipv6@ietf.org" Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AQHMEXNYf+V3/K1jwk2ucgUWFKlw4pSLMxgAgAAB4ACAABuyAIACkGgA Date: Sun, 15 May 2011 13:14:16 +0000 Message-ID: In-Reply-To: <4DCD72C4.2070806@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <33D8808F8102E4438D5972F8612BEE89@cable.comcast.com> Content-Transfer-Encoding: quoted-printable 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: Sun, 15 May 2011 13:14:23 -0000 Alex, In DOCSIS deployments there are no issue with RAs and we do know how to configure the default route. DHCPv6 is used mainly for address, prefix, and configuration information. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 5/13/11 2:04 PM, "Alexandru Petrescu" wrote: >(your dhcp-should text seems to be saying operators dont like RA for >some cases, hence they dont know how to configure the default route for >these cases, hence DHCP should, and MIF doesnt lifetime). > From john_brzozowski@cable.comcast.com Sun May 15 06:19: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 BFB25E067E for ; Sun, 15 May 2011 06:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.865 X-Spam-Level: X-Spam-Status: No, score=-105.865 tagged_above=-999 required=5 tests=[AWL=2.598, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 L3nXiAJqc8yy for ; Sun, 15 May 2011 06:19:48 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 48194E0651 for ; Sun, 15 May 2011 06:19:48 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.123180250; Sun, 15 May 2011 09:19:44 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Sun, 15 May 2011 09:19:44 -0400 From: "Brzozowski, John" To: "Manfredi, Albert E" , Ed Jankiewicz Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AQHMEXNYf+V3/K1jwk2ucgUWFKlw4pSLLJsAgAAB1ICAAAWhAIAAQLgAgAADNACAAmqZgA== Date: Sun, 15 May 2011 13:19:43 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 15 May 2011 13:19:50 -0000 Bert, I sent some mail earlier on this topic. We do require it for provisioning via the WAN interface. On the LAN we aim to ensure there is greater flexibility. I just want to make sure it is clear that cable broadband does not require the use of DHCPv6 in the premise. This is a local policy/technical decision. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 5/13/11 4:25 PM, "Manfredi, Albert E" wrote: >Ed Jankiewicz wrote: > >> The comment from Tim that the DHCPv6 man not be of use in SOHO >> deployments, I think SHOULD still leaves enough wiggle room for a >> variety of implementations with different feature sets. > >I support SHOULD for DHCPv6 as well. > >But responding to the above, purely parenthetically, would DOCSIS be out >of the question in a SOHO network? If not, and I think not, then we have >been hearing that cable networks do use DHCP. So it would become >mandatory is SOHO nets that depend on cable broadband. > >Bert > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From timbeck04@verizon.net Sun May 15 12:40:42 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 D96BDE06AF for ; Sun, 15 May 2011 12:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.448 X-Spam-Level: X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_AVOID=2.3, STOX_REPLY_TYPE=0.001] 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 FRt6RBHud7eB for ; Sun, 15 May 2011 12:40:41 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by ietfa.amsl.com (Postfix) with ESMTP id B797AE0670 for ; Sun, 15 May 2011 12:40:41 -0700 (PDT) Received: from bessy ([unknown] [173.48.247.217]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LL900FRR5BGJAQ0@vms173017.mailsrvcs.net> for ipv6@ietf.org; Sun, 15 May 2011 14:40:31 -0500 (CDT) Message-id: <9E6C3AAD0522482581EBF333F6582E97@bessy> From: "Timothy E. Enos" To: "Bob Hinden" References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <96DF83B6DC524A8EA916AA027F27FA4E@bessy> <78BCA97B-E2C0-4527-A4A0-6578911800EF@gmail.com> Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Date: Sun, 15 May 2011 15:40:34 -0400 MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: Thomas Narten , 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, 15 May 2011 19:40:43 -0000 Hi Bob, Thanks for your reply. I would say that partly because there are so many different deployment models that MAY is precisely what is informed here. That said, an acceptable alternative for me would be that it be SHOULD for both DHCPv6 and SLAAC. DHCP certainly fills a void in IPv4, i.e. the dynamic configuration of hosts (i.e. nodes that are not routers). IMO it just isn't as necessary in IPv6 as it is in IPv4, as there is no SLAAC-like functionality built into IPv4. Further, it seems to me that SLAAC can be extended to do more for configuring IPv6 hosts akin to what DHCP does for IPv4 hosts. So, we currently have two extant standardized ways to dynamically configure hosts in IPv6: DHCPv6 and SLAAC. I don't have any qualms about there being two different ways to configure IPv6 hosts and understand some do. I certainly don't have any qualms about there being more than one standardized way to do IPv6 PD either. Something that was ostensibly first created to address a need to dynamically configure IPv4 hosts was further extended to allocate IPv6 prefixes to routers. FWIW, here is a paper that examines a few different PD and CD (i.e. certificate distribution) mechanisms: http://mobisend.org/SP1b.pdf. I'm simply sharing my opinion, and appreciate this forum. This is my last post on the topic, and respectfully defer to group consensus on this issue. Thanks, Tim Ps 127:3-5 ----- Original Message ----- From: "Bob Hinden" To: "Timothy E. Enos" Cc: "Bob Hinden" ; "Thomas Narten" ; Sent: Friday, May 13, 2011 12:40 PM Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD > Timothy, > > On May 13, 2011, at 9:28 AM, Timothy E. Enos wrote: > >> Hi Thomas, >> >> Thanks for posting this. >> >> IMO, a SHOULD is not required in a SOHO environment (which is arguably >> not a corner case for deployment). MAY works. >> >> Just as some environments may require the use of DHCPv6, some >> environments may not. >> >> For those that require use of DHCPv6, they MAY use it. >> >> I think at least in the SOHO context, it's really the local >> administrative policies (not hard and fast technical factors) that >> determine the (lack of) need for DHCPv6. >> >> All the above said, my personal opinion is that DHCPv6 does not need to >> elevated to SHOULD from MAY for the node requirements spec. If the group >> decides to the contrary I can certainly accept that. > > I think all we are trying to say that there are a wide range of deployment > models, that we recommend that hosts SHOULD support both. We are not > making any statement about what should be used in a particular deployment. > > Or at least, that's my thinking and why I support the SHOULD. Also, why I > suggested changing the text to not talk about "operators". > > Bob > > > >> >> My $0.02, >> >> Tim >> Ps 127:3-5 >> >> ----- Original Message ----- From: "Thomas Narten" >> To: >> Sent: Friday, May 13, 2011 9:37 AM >> Subject: Node Requirements: Elevating DHCPv6 from MAY to SHOULD >> >> >>> Per a previous thread, there are indications that the WG may now be >>> willing to recommend that DHCPv6 be a SHOULD for all hosts. This is >>> based on the following rationale: >>> >>> Thomas Narten writes: >>> >>>> I personally would support having DHCP be a SHOULD rather than a >>>> MAY. The justification in my mind is that if you want the network >>>> operator to have the choice of whether they want to use Stateless >>>> addrconf OR DHCP, they only have that choice of devices widely >>>> implement both. >>> >>> This was supported by some others, particularly now that it is clear >>> there are more implementations of DHCPv6, e.g.: >>> >>> Bob Hinden writes: >>> >>>> While my personal view is that DHCPv6 won't be used for host >>>> configuration in cable/DSL deployments (except for provisioning the >>>> prefix to the home router), it appears that DHCPv6 is being widely >>>> implemented in host OS's because it is needed some environments. >>>> There are enough variations in deployment models that a host >>>> developer will need to support both. >>> >>>> Based on this, I think a SHOULD is OK. >>> >>> Let me propose the following change be made to the node requirements >>> document: >>> >>> OLD/Current: >>> >>> DHCP can be used to obtain and configure addresses. In general, a >>> network may provide for the configuration of addresses through Router >>> Advertisements, DHCP or both. At the present time, the configuration >>> of addresses via stateless autoconfiguration is more widely >>> implemented in hosts than address configuration via DHCP. However, >>> some environments may require the use of DHCP and may not support the >>> configuration of addresses via RAs. Implementations should be aware >>> of what operating environment their devices will be deployed. Hosts >>> MAY implement address configuration via DHCP. >>> >>> New: >>> >>> DHCPv6 can be used to obtain and >>> configure addresses. In general, a network may provide for the >>> configuration of addresses through Router Advertisements, >>> DHCPv6 or both. Some operators have indicated that they do >>> not intend to support stateless address autoconfiguration on >>> their networks and will require all address assignments be >>> made through DHCPv6. On such networks, devices that support >>> only stateless address autoconfiguration will be unable to >>> automatically configure addresses. Consequently all hosts >>> SHOULD implement address configuration via DHCP. >>> >>> >>> Is this acceptable? >>> >>> Please respond yes or no. Given the WG's previous hesitation to having >>> DHCPv6 be a SHOULD, it is important that we get a clear indication of >>> whether or not the WG supports this change. >>> >>> Thomas >>> -------------------------------------------------------------------- >>> 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 brian.e.carpenter@gmail.com Sun May 15 13:55:38 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 87EDFE06AF for ; Sun, 15 May 2011 13:55:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+tkl4gsLM0g for ; Sun, 15 May 2011 13:55:38 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7A6E069D for ; Sun, 15 May 2011 13:55:38 -0700 (PDT) Received: by pvh18 with SMTP id 18so1436967pvh.31 for ; Sun, 15 May 2011 13:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Jl3b6S9HXqOKCgatf9WhR7dKvCHm1vN5yyA2T5aheTw=; b=go82WIo8BcCVskQIEGHQJeWiXp4ZnZ59ukoQIJZC2FCPYHJEkYWYe7STANeZbFCiW8 J1u2eUJI0od4IS13RU6uVpiS7f2LNfeHhOjx2dEIHm9NGkGLQea4ZvaZ48F63lit3uMY Wbb2HNCYYRZMpIMBh6j3rX1EV/vxZvMswxiWs= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=SrynagFAX6K3MU55REXXrx1V3GyH+FgTH2YazK/fndKW8P9tR91S/GLJcJjg6ICb+G nXNJPKC1+kZ5iQvagl9nlpCAGR1yxXiJFv/9JsG7edvLcW+JOsm8U3NRIAQ6/R4TZxC5 ecOPByLvVqdg9GLJWhT7aDfMxXbYMRxE8Xu6g= Received: by 10.142.140.14 with SMTP id n14mr2254320wfd.407.1305492937833; Sun, 15 May 2011 13:55:37 -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 n7sm4068921wfl.23.2011.05.15.13.55.35 (version=SSLv3 cipher=OTHER); Sun, 15 May 2011 13:55:36 -0700 (PDT) Message-ID: <4DD03DBF.2030705@gmail.com> Date: Mon, 16 May 2011 08:55:27 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Timothy E. Enos" Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <96DF83B6DC524A8EA916AA027F27FA4E@bessy> <78BCA97B-E2C0-4527-A4A0-6578911800EF@gmail.com> <9E6C3AAD0522482581EBF333F6582E97@bessy> In-Reply-To: <9E6C3AAD0522482581EBF333F6582E97@bessy> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , ipv6@ietf.org, Bob Hinden 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, 15 May 2011 20:55:38 -0000 On 2011-05-16 07:40, Timothy E. Enos wrote: > Hi Bob, > > Thanks for your reply. I would say that partly because there are so many > different deployment models that MAY is precisely what is informed here. > That said, an acceptable alternative for me would be that it be SHOULD > for both DHCPv6 and SLAAC. I am certain that SLAAC remains a MUST. We need stand-alone networks to configure themselves; that was a very early requirement for IPng. Brian From kawamucho@mesh.ad.jp Sun May 15 17:17: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 77DA1E06E5 for ; Sun, 15 May 2011 17:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 aZSYrftzqgwu for ; Sun, 15 May 2011 17:17:36 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id DBD5CE06D7 for ; Sun, 15 May 2011 17:17:35 -0700 (PDT) Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id p4G0HXqR027504 for ; Mon, 16 May 2011 09:17:33 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id p4G0HXl15186 for ipv6@ietf.org; Mon, 16 May 2011 09:17:33 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id p4G0HX8c021839 for ; Mon, 16 May 2011 09:17:33 +0900 (JST) Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id p4G0HX1V021519 for ; Mon, 16 May 2011 09:17:33 +0900 Received: from [127.0.0.1] ([10.84.99.90]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id p4G0HXYo010535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 May 2011 09:17:33 +0900 Message-ID: <4DD06D1C.8060904@mesh.ad.jp> Date: Mon, 16 May 2011 09:17:32 +0900 From: Seiichi Kawamura User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> <20110514.012152.41686540.sthaug@nethelp.no> <4DCDBF77.90604@innovationslab.net> In-Reply-To: <4DCDBF77.90604@innovationslab.net> X-Enigmail-Version: 1.1.1 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: Mon, 16 May 2011 00:17:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just read this thread. This is so great. Thanks to Thomas and all for the new text. Seiichi (2011/05/14 8:32), Brian Haberman wrote: > All, > The chairs have determined that there is a strong consensus to > elevate DHCPv6 to SHOULD support in the node requirements document. > Since this is the last open issue with this document, the chairs will > begin the advancement process when a new version is published. > > Regards, > Brian & Bob > > On 5/13/11 7:21 PM, sthaug@nethelp.no wrote: >>>> Per a previous thread, there are indications that the WG may now be >>>> willing to recommend that DHCPv6 be a SHOULD for all hosts. This is >>>> based on the following rationale: >>> >>> I support moving it to SHOULD. >> >> Agreed. >> >> Steinar Haug, Nethelp consulting, sthaug@nethelp.no >> -------------------------------------------------------------------- >> 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 > -------------------------------------------------------------------- > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iEYEARECAAYFAk3QbRsACgkQcrhTYfxyMkJyZwCfYnUcMHcKh4SCkqGsNOOJ7Zgl cyYAn0fXK5VUi+/1HxN21CDr6Tbr33i2 =hyQA -----END PGP SIGNATURE----- From Fred.L.Templin@boeing.com Mon May 16 08:50: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 99E1FE071C; Mon, 16 May 2011 08:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 A9j1vhsoZVVV; Mon, 16 May 2011 08:50:26 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 13171E06CF; Mon, 16 May 2011 08:50:25 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4GFoNn4024883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 May 2011 10:50:24 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p4GFoMqD014099; Mon, 16 May 2011 08:50:22 -0700 (PDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4GFoJKI013761 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 16 May 2011 08:50:19 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Mon, 16 May 2011 08:50:19 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" , "ipv6@ietf.org" Date: Mon, 16 May 2011 08:50:18 -0700 Subject: RFC3484, Section 6, Rule 7 and ISATAP Thread-Topic: RFC3484, Section 6, Rule 7 and ISATAP Thread-Index: AcwTst19svhVZRm1TjCUP8r7MCuobQAKi9Rg Message-ID: References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org><4DC8D717.3080402@redpill-linpro.com><2011 0510064904.B5081E9E11B@drugs.dv.isc.org><4DCA5121.9010809@redpill-linpro.co m><20110511121453.D438CEAA1A5@drugs.dv.isc.org><0F0C1186-50F6-4305-92E0-B83 3C0520127@employees.org><20110511144736.77E3AEAAEDA@drugs.dv.isc.org><4DCAC 64C.7030607@redpill-linpro.com><20110511232129.A5DFDEAD470@drugs.dv.isc.org ><4DCB7609.3020802@redpill-linpro.com><20110512073353.EB4CCEB0BC6@drugs.dv. isc.org><4DCBC1F1.7030600@redpill-linpro.com><20110515231723.5DEB8EBE245@drugs.dv.isc.org><20110516062459.94D4CEC26F2@drugs.dv.isc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Mon, 16 May 2011 15:50:26 -0000 Recently, there was discussion regarding how to discern an ISATAP IPv6 address from a native IPv6 address, and an implication that this may have some bearing on RFC3484 address selection. The correct answer is that an IPv6 address is an ISATAP address IFF it is assigned to an ISATAP interface, i.e., a node can tell that its IPv6 source address is ISATAP by examining the interface to which the address is assigned. Therefore, there is a way for a node to prefer native IPv4 over ISATAP even though an IPv6 address cannot be identified as ISATAP solely by examining the prefix. This policy is manifested in RFC3484, Section 6, Rule 7: "Rule 7: Prefer native transport. If DA is reached via an encapsulating transition mechanism (e.g., IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is reached via encapsulation and DA is not, then prefer DA. Discussion: 6-over-4 [15], ISATAP [16], and configured tunnels [17] are examples of encapsulating transition mechanisms for which the destination address does not have a specific prefix and hence can not be assigned a lower precedence in the policy table. An implementation MAY generalize this rule by using a concept of interface preference, and giving virtual interfaces (like the IPv6-in-IPv4 encapsulating interfaces) a lower preference than native interfaces (like ethernet interfaces)." Although the Discussion shows a "MAY", the rule itself asserts that the native transport is to be preferred over an encapsulating transport. Hence, there is no particular reason for an ISATAP host to avoid placing AAAA records in the DNS for any of its SLAAC-derived ISATAP addresses. Fred fred.l.templin@boeing.com= From Dmitry.Anipko@microsoft.com Mon May 16 12:47:53 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 7ED75E07AA; Mon, 16 May 2011 12:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 63UmTw-wL8Ov; Mon, 16 May 2011 12:47:52 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id DC2E6E07A7; Mon, 16 May 2011 12:47:52 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 16 May 2011 12:47:52 -0700 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Mon, 16 May 2011 12:47:52 -0700 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Mon, 16 May 2011 12:47:52 -0700 From: Dmitry Anipko To: "Templin, Fred L" , "v6ops@ietf.org" , "ipv6@ietf.org" Date: Mon, 16 May 2011 12:47:51 -0700 Subject: RE: RFC3484, Section 6, Rule 7 and ISATAP Thread-Topic: RFC3484, Section 6, Rule 7 and ISATAP Thread-Index: AcwTst19svhVZRm1TjCUP8r7MCuobQAKi9RgAAkUPbA= Message-ID: References: <20110509080848.D2CB7E97C8E@drugs.dv.isc.org><4DC8D717.3080402@redpill-linpro.com><2011 0510064904.B5081E9E11B@drugs.dv.isc.org><4DCA5121.9010809@redpill-linpro.co m><20110511121453.D438CEAA1A5@drugs.dv.isc.org><0F0C1186-50F6-4305-92E0-B83 3C0520127@employees.org><20110511144736.77E3AEAAEDA@drugs.dv.isc.org><4DCAC 64C.7030607@redpill-linpro.com><20110511232129.A5DFDEAD470@drugs.dv.isc.org ><4DCB7609.3020802@redpill-linpro.com><20110512073353.EB4CCEB0BC6@drugs.dv. isc.org><4DCBC1F1.7030600@redpill-linpro.com><20110515231723.5DEB8EBE245@drugs.dv.isc.org><20110516062459.94D4CEC26F2@drugs.dv.isc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Mon, 16 May 2011 19:47:53 -0000 Hello Fred, Rule 7 does help to distinguish native IPv6 versus ISATAP.=20 However, rule 7 doesn't help to distinguish ISATAP from native IPv4: the ru= le 7 is only considered after rule 6, and per rule 6 ISATAP is already prio= ritized higher than IPv4 due to the default prefix policy table precedence = values. As a result, rule 7 won't apply in that case, and ISATAP is preferr= ed over IPv4. I'm not weighing in on whether that is a problem or not, but trying to clar= ify what I believe the raised concern was. Thank you, Dmitry -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Tem= plin, Fred L Sent: Monday, May 16, 2011 8:50 AM To: v6ops@ietf.org; ipv6@ietf.org Subject: RFC3484, Section 6, Rule 7 and ISATAP Recently, there was discussion regarding how to discern an ISATAP IPv6 address from a native IPv6 address, and an implication that this may have some bearing on RFC3484 address selection. The correct answer is that an IPv6 address is an ISATAP address IFF it is assigned to an ISATAP interface, i.e., a node can tell that its IPv6 source address is ISATAP by examining the interface to which the address is assigned. Therefore, there is a way for a node to prefer native IPv4 over ISATAP even though an IPv6 address cannot be identified as ISATAP solely by examining the prefix. This policy is manifested in RFC3484, Section 6, Rule 7: "Rule 7: Prefer native transport. If DA is reached via an encapsulating transition mechanism (e.g., IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is reached via encapsulation and DA is not, then prefer DA. Discussion: 6-over-4 [15], ISATAP [16], and configured tunnels [17] are examples of encapsulating transition mechanisms for which the destination address does not have a specific prefix and hence can not be assigned a lower precedence in the policy table. An implementation MAY generalize this rule by using a concept of interface preference, and giving virtual interfaces (like the IPv6-in-IPv4 encapsulating interfaces) a lower preference than native interfaces (like ethernet interfaces)." Although the Discussion shows a "MAY", the rule itself asserts that the native transport is to be preferred over an encapsulating transport. Hence, there is no particular reason for an ISATAP host to avoid placing AAAA records in the DNS for any of its SLAAC-derived ISATAP addresses. Fred fred.l.templin@boeing.com -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From richih.mailinglist@gmail.com Tue May 17 08:48:03 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 6109CE0777 for ; Tue, 17 May 2011 08:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 CR1FlyHOzpKS for ; Tue, 17 May 2011 08:48:02 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B709EE0759 for ; Tue, 17 May 2011 08:47:43 -0700 (PDT) Received: by iwn39 with SMTP id 39so688967iwn.31 for ; Tue, 17 May 2011 08:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=BPFB1ti0knLX/QjI5eVNvwKhsHwm/abEjv+7GQ64dBs=; b=bvKtux5yYnPc6hiAHuJL5jcz7Cj7qHChCE0svTzlO5g0662+EtxE9Auotf53+cxXI2 1mZv6xYGgArpJ/hHd1RNsuZmF1yRs0s6iPUlpVcjDEAecX8/f1XZnyf4Gbdwrc7+2d94 qEpH+CrKklb3OpoJOLJ0Z8HQrU1MGjha3/5eE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=tzNcZ9+fV2LceTuqxT9+LYOgj/XnrgXVl6x1n+RzHhfQLV36CW3Vnb2TlyU9lyQCzA j+CLwueHDC5Dfa3ctFTf9yissd+zxP5Nm53XWX/HzGb6j1vwCFJfo9l0c1IFQMlOlGy5 5G8Z1mKjLfDL/kbiIxGMbw+3ZImJDcDX3efU8= Received: by 10.231.18.220 with SMTP id x28mr526853iba.185.1305647263083; Tue, 17 May 2011 08:47:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.14.137 with HTTP; Tue, 17 May 2011 08:47:22 -0700 (PDT) From: Richard Hartmann Date: Tue, 17 May 2011 17:47:22 +0200 Message-ID: Subject: Adapting draft-hartmann-6man-addresspartnaming as a WG item To: 6man List Content-Type: text/plain; charset=UTF-8 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, 17 May 2011 15:48:03 -0000 Hi all, I would like to officially ask that our draft is accepted as a WG item. If it's accepted, we get out of the stale-mate and if it's rejected, I can stop wasting time on it :) Afaik, this will be decided upon at the next IETF conference? Thanks, Richard [1] http://tools.ietf.org/html/draft-hartmann-6man-addresspartnaming I From rja.lists@gmail.com Wed May 18 10:32:01 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 77426E06B9 for ; Wed, 18 May 2011 10:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ooNLl23R75dq for ; Wed, 18 May 2011 10:32:00 -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 54087E0714 for ; Wed, 18 May 2011 10:32:00 -0700 (PDT) Received: by vxg33 with SMTP id 33so1530834vxg.31 for ; Wed, 18 May 2011 10:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=6IR4UYUQjE9OFrRB7LsmbWyyKOZb9FJONQf9Ooh9Eco=; b=VHTN41c9Vd/pzFNpWRyjPQHTnTjlwoDYxuhTKGoUPASl2+Gxsu03ftK/tSVLiI0Mkv MA4dUwpCXv/h9S8Y2oAuFouh0xpPFdQkS693JyyZlWee7laEdPtbcOBJB2m5dm5T9/Wv +tjFpl2NpPfU25/wh9TotHkWMiDVFDMAcv0q4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=h5wT0N1GU9fBlcM8bYqB1ebaIMeC2bVeYWvFXhWCUcvAohFjc8VLRXuZ+EE+1X4hws 6zUno7Jkf6uPQA3j9AtSErKcPczGegc+XWI5yCEnqGopkhjeVps2FLRXaYLHZWB1AzBF tW+GP9qdPR0e2JChCMqo4w3XXfi2kMFsamo94= Received: by 10.52.176.101 with SMTP id ch5mr3244718vdc.129.1305739919625; Wed, 18 May 2011 10:31:59 -0700 (PDT) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id b5sm384561vcx.28.2011.05.18.10.31.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2011 10:31:58 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Adapting draft-hartmann-6man-addresspartnaming as a WG item Date: Wed, 18 May 2011 13:31:56 -0400 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 18 May 2011 17:32:01 -0000 I regret to say that I find the proposal in this I-D confusing, likely to increase confusion, and also likely to create avoidable complexity in other IPv6 WG documents. I don't believe the claimed problem described in the draft is an actual problem, either now or during the past ~15 years of IPv6 work in the IETF. So I am afraid that I can't support this document in its current form. Yours, Ran From brian@innovationslab.net Wed May 18 10:44:37 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 44187E06C3 for ; Wed, 18 May 2011 10:44:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7Vdvh6DmWld for ; Wed, 18 May 2011 10:44:36 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id C5ECCE06AD for ; Wed, 18 May 2011 10:44:35 -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 B4AE088132 for ; Wed, 18 May 2011 10:37:10 -0700 (PDT) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 4CB831369423 for ; Wed, 18 May 2011 10:44:35 -0700 (PDT) Message-ID: <4DD40582.40005@innovationslab.net> Date: Wed, 18 May 2011 13:44:34 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: IPv6 WG Mailing List Subject: Consensus call on adopting: draft-hartmann-6man-addressnaming X-Enigmail-Version: 1.1.1 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, 18 May 2011 17:44:37 -0000 All, This starts a 2-week consensus call on adopting: Title : Naming IPv6 address parts Author(s) : L. Donnerhacke, et al. Filename : draft-hartmann-6man-addresspartnaming-01.txt Pages : 8 Date : 2011-05-06 as a 6MAN WG document. Please state your opinion (either for or against) on making this draft a WG draft either on the mailing list or to the chairs. This call will end on May 1, 2011. Regards, Brian & Bob From scott.brim@gmail.com Wed May 18 11:11:10 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 47843E0770 for ; Wed, 18 May 2011 11:11:10 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZkZTijpcrJ2 for ; Wed, 18 May 2011 11:11:09 -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 26BC7E0766 for ; Wed, 18 May 2011 11:11:09 -0700 (PDT) Received: by mail-vw0-f44.google.com with SMTP id 12so1590996vws.31 for ; Wed, 18 May 2011 11:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=Nus2IvfACiCzbWCQI7O9rdlfkUNhylqABlbRaDyn6Wk=; b=RFJh78jM9ZW4LroLpbsdIPzZAXjfeNsukJJ4iWZWuaUAEm6gIQll0pCICYQabSgwtj b0cixNhEgWIAjSsRhpX88/ZtDgWvlT9HjLiZlRN1vOny5y/QjL/CIhKMhjry5ckRJmxd CoqXWU6bYRSwQxak4R83S5LzQdZUqOQaH/e48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=MF1ePlHQqJRb6t6pyeqkbVdI5IuyXTqWxZaRwRqkqTD6ziAmMocX0x0FGkHei6fl02 bIQ7pNLhV0rGITACZdEb8hSAIoVLkz9Cof3iWP+QjiBQwy45JRuv1/4bbaJTVKryPDkj 3ZTJ6+/pEu/JzIlompojQgxjCs+iJWFbNqtPU= Received: by 10.52.69.2 with SMTP id a2mr3354508vdu.5.1305742268885; Wed, 18 May 2011 11:11:08 -0700 (PDT) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id q2sm806931vbv.22.2011.05.18.11.11.07 (version=SSLv3 cipher=OTHER); Wed, 18 May 2011 11:11:08 -0700 (PDT) Message-ID: <4DD40BBA.6080507@gmail.com> Date: Wed, 18 May 2011 14:11:06 -0400 From: Scott Brim User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: RJ Atkinson Subject: Re: Adapting draft-hartmann-6man-addresspartnaming as a WG item References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 18 May 2011 18:11:10 -0000 I don't see a lot of consensus on either the urgency or the solution. Some say whatever they're using now is fine for them. Others say they don't like the proposed names. I think this draft could possibly be published as an informational suggestion, but we should let the "problem" ripen for a while longer before pushing convergence on a universal solution. From br.silvestre@gmail.com Wed May 18 11:17:18 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 6C628E0763 for ; Wed, 18 May 2011 11:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.383 X-Spam-Level: X-Spam-Status: No, score=-3.383 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 wRGUJAYk6sUp for ; Wed, 18 May 2011 11:17:17 -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 7A8FFE0737 for ; Wed, 18 May 2011 11:17:17 -0700 (PDT) Received: by vxg33 with SMTP id 33so1572579vxg.31 for ; Wed, 18 May 2011 11:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4Fimvj4SJk9W1nMOTtfd/PPuUZ9WD3vQcWqQ/elCJuU=; b=KlC3sIwO4eH06oX/wN54Ntjj3MW11NsW4fH0poek8QyooNZAkCugn2GGJjLWrxI4ax KwqcMAq3qkWerTjK/0wHLRWcWdMJOv5m9oGu1YNOatJwHGgvf3FVOkpsoOElo3ML4Vk3 LX1ibXX80F4pAo2w1aKc8NycAxSeq6+M9ISJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WUrXwmo8E8nHeUQHcdDCSsExNj2LJmuBQueK3K8CzqycJ8NPSawf00SQEfkZ6PGC4K zh08f6yf1ekMGXFdfzNBRnaz66ECg91+ZvUL3q4c0yIwtxMboSfOR0ld/vJ5JU+4xc5A EeVao7pS8T0siJwe3yIyvugLPKvJlZXGGaROY= MIME-Version: 1.0 Received: by 10.52.100.136 with SMTP id ey8mr3135279vdb.136.1305742637055; Wed, 18 May 2011 11:17:17 -0700 (PDT) Received: by 10.52.101.167 with HTTP; Wed, 18 May 2011 11:17:17 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 May 2011 19:17:17 +0100 Message-ID: Subject: Re: DNS configuration for Wireless networks using Router Advertisement From: Bruno Silvestre To: jaehoon.paul@gmail.com Content-Type: multipart/alternative; boundary=20cf307c9c420cc0cb04a390e6cf Cc: ipv6@ietf.org, Nuno Veiga , Carlos , soohong.park@samsung.com, pjeong@brocade.com 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, 18 May 2011 18:17:18 -0000 --20cf307c9c420cc0cb04a390e6cf Content-Type: text/plain; charset=ISO-8859-1 Dear All ! We found the solution of the problem. There was a problem in the clients side and not in the 'radvd' service. In fact, 'Windows 7 and Vista' clients do not consider the RDNSS option advertised by radvd. In linux clients like Ubuntu 10.04, we installed a daemon to solve this. In Ubuntu 11.04, there is no need to install any daemon. For windows 7 and Vista, we had to install a program called 'rdnssd_win32', which is an implementation of the RFC 6106 for Microsoft Windows. It parses the RDNSS options present in Router Advertisement (RA), get the DNS nameservers and write them in the registry. Many thanks for your support, Bruno. 2011/5/17 Bruno Silvestre > Dear Mr. Jeong, > > I am currently developping an IPv6 project for University purposes for > wireless networks and mobile devices. > > We configured radvd (router advertisement) to advertise a prefix in order > to enable the AutoConfiguration of the hosts. > > This process works fine. > > However, we encounter problems to advertise DNS configuration. > > In fact, it seems that Android devices ( SDK 2.2 and 2.3 mobile phones) do > not support DHCPv6, and so we should advertise the DNS configuration (DNS > servers) by using Router Advertisement ?? > > According the RFC6106, this should be possible... > > But it seems that 'radvd' ignores the RDNSS and DNSSL options... > > We are running 'radvd' under Ubuntu Server. > > Is there any way to advertise the DNS configuration via Router > Advertisement with radvd ? > Do you know about some 'radvd' version, which can run these configurations > for Ubuntu Server ? > We are currently running radvd 1.6. > > Thank you very much in advance, > > Bruno > > P.S: Here comes our radvd.conf file: > > #radvd.conf > *interface eth1 > { > AdvSendAdvert on; > AdvManagedFlag off; > AdvOtherConfigFlag off; > prefix 2001:690:2060::/64 > { > AdvOnLink on; > AdvAutonomous on; > };* > > * > * > > *# Advertise DNS server ??* > > *RDNSS 2001:690:2060::2 > { > AdvRDNSSPreference 8; > AdvRDNSSOpen off; > AdvRDNSSLifetime 3600; > }; > };* > > > > > --20cf307c9c420cc0cb04a390e6cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear All !

We found the solution of the problem.

There was a problem in the clients side and not in the &#= 39;radvd' service.

In fact, 'Windows 7 and= Vista' clients do not consider the RDNSS option advertised by radvd.

In linux clients like Ubuntu 10.04, we installed a daem= on to solve this.
In Ubuntu 11.04, there is no need to install an= y daemon.

For windows 7 and Vista, we had to insta= ll a program called 'rdnssd_win32', which is an=A0implementation of= the RFC 6106 for Microsoft Windows. It parses the RDNSS options=A0present = in Router Advertisement (RA), get the DNS nameservers and write them in the= registry.

Many thanks for your support,

= Bruno.

2011/5/17 Bruno Silvestre <br.silvestre@gmail.= com>
Dear Mr. Jeong,

I am cur= rently developping an IPv6 project for University purposes for wireless net= works and mobile devices.

We configured radvd (router advertisement) to advertise= a prefix in order to enable the AutoConfiguration of the hosts.

This process works fine.

Howev= er, we encounter problems to advertise DNS configuration.

In fact, it seems that Android devices ( SDK 2.2 and 2.3 mobile pho= nes) do not support DHCPv6, and so we should advertise the DNS configuratio= n (DNS servers) by using Router Advertisement ??

According the RFC6106, this should be possible...
=

But it seems that 'radvd' ignores the RDNSS and= DNSSL options...

We are running 'radvd' u= nder Ubuntu Server.

Is there any way to advertise the DNS configuration via= Router Advertisement with radvd ?
Do you know about some 'ra= dvd' version, which can run these configurations for Ubuntu Server ?
We are currently running radvd 1.6.=A0

Thank = you very much in advance,

Bruno

P.S: Here comes our radvd.conf file:

#radvd.conf

interface eth1
{
    AdvSendAdvert on;
    AdvManagedFlag off;
    AdvOtherConfigFlag off;
    prefix 2001:690:2060::/64
  {
       AdvOnLink on;
       AdvAutonomous on;
  };

# Advertise DNS server ??
RDNSS 2001:690:2060::2
{
        AdvRDNSSPreference 8;
        AdvRDNSSOpen off;
        AdvRDNSSLifetime 3600;
};
};



=

--20cf307c9c420cc0cb04a390e6cf-- From Wesley.E.George@sprint.com Wed May 18 11:44:12 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 4EA1BE06B0 for ; Wed, 18 May 2011 11:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 TQ20oL2uEYFV for ; Wed, 18 May 2011 11:44:11 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 40906E06CF for ; Wed, 18 May 2011 11:44:10 -0700 (PDT) Received: from mail192-ch1-R.bigfish.com (216.32.181.174) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.8; Wed, 18 May 2011 18:44:09 +0000 Received: from mail192-ch1 (localhost.localdomain [127.0.0.1]) by mail192-ch1-R.bigfish.com (Postfix) with ESMTP id 75B61F60182; Wed, 18 May 2011 18:44:09 +0000 (UTC) X-SpamScore: -35 X-BigFish: VS-35(zz936eK9371O542Mzz1202hzz8275dh1033ILz2fh2a8h668h839h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:plsasdm1.corp.sprint.com; RD:smtpls1.sprint.com; EFVD:NLI Received: from mail192-ch1 (localhost.localdomain [127.0.0.1]) by mail192-ch1 (MessageSwitch) id 130574424980861_17019; Wed, 18 May 2011 18:44:09 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail192-ch1.bigfish.com (Postfix) with ESMTP id 1086B2C004E; Wed, 18 May 2011 18:44:09 +0000 (UTC) Received: from plsasdm1.corp.sprint.com (144.230.168.25) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 18 May 2011 18:44:05 +0000 Received: from PLSWEH05.ad.sprint.com (PLSWEH05.corp.sprint.com [144.226.251.23]) by plsasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p4IIhqiN017794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 May 2011 13:44:05 -0500 Received: from PDAWM12B.ad.sprint.com ([fe80::64c8:fd69:1029:79b0]) by PLSWEH05.ad.sprint.com ([2002:90e2:fb17::90e2:fb17]) with mapi id 14.01.0270.001; Wed, 18 May 2011 13:44:04 -0500 From: "George, Wes E [NTK]" To: Brian Haberman , IPv6 WG Mailing List Subject: RE: Consensus call on adopting: draft-hartmann-6man-addressnaming Thread-Topic: Consensus call on adopting: draft-hartmann-6man-addressnaming Thread-Index: AQHMFYNrYWpPiLItUkGECJYcjKodUpSS4OpQ Date: Wed, 18 May 2011 18:44:03 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10D6407F@PDAWM12B.ad.sprint.com> References: <4DD40582.40005@innovationslab.net> In-Reply-To: <4DD40582.40005@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.23] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_011A_01CC156A.07AFF330" MIME-Version: 1.0 X-OriginatorOrg: sprint.com 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, 18 May 2011 18:44:12 -0000 ------=_NextPart_000_011A_01CC156A.07AFF330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit With no disrespect intended to the authors... I agree that there is no universally accepted name for an IPv6 address part, but IMO IETF and this WG has much larger things to be concerned with than how to name IPv6 address parts, and adopting a document like this makes it seem like we have nothing better to do and trivializes the other work that we actually need people to pay attention to. It's fine as an individual submission, it doesn't need a WG to "help" it along, and there's no clear consensus based on the discussion thus far anyway. Wes George -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Wednesday, May 18, 2011 1:45 PM To: IPv6 WG Mailing List Subject: Consensus call on adopting: draft-hartmann-6man-addressnaming All, This starts a 2-week consensus call on adopting: Title : Naming IPv6 address parts Author(s) : L. Donnerhacke, et al. Filename : draft-hartmann-6man-addresspartnaming-01.txt Pages : 8 Date : 2011-05-06 as a 6MAN WG document. Please state your opinion (either for or against) on making this draft a WG draft either on the mailing list or to the chairs. This call will end on May 1, 2011. Regards, Brian & Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- ------=_NextPart_000_011A_01CC156A.07AFF330 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXAjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggaPMIIFd6ADAgECAgpI LDrNAAAANdzuMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMTEwNDExMTUxNDQyWhcNMTQwNDEw MTUxNDQyWjCBszETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxETAPBgNVBAsTCFN0YW5k YXJkMRswGQYDVQQDExJXZXNsZXkgRSBHZW9yZ2UgSVYxKTAnBgkqhkiG9w0BCQEWGldlc2xleS5F Lkdlb3JnZUBzcHJpbnQuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCygiN7DhzJmgJ2 ZWuBANKioX8ZIF1vruw2UTxd0ORpKSXEO8B+x3AnmFkNFTh3FGi00Ggw8Sk4MKbT6xJsDn9yWXS4 WoIVtZBFiC/9zkYFcJZyy2nza+ca4cyRkgEGeuo3AwERoL6Ky0VR0T4gmFbf7j+yOG5uSDl0kOwM XNiBdQIDAQABo4IDYTCCA10wCwYDVR0PBAQDAgWgMDYGCSqGSIb3DQEJDwQpMCcwDQYIKoZIhvcN AwICATgwDQYIKoZIhvcNAwQCATgwBwYFKw4DAgcwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUI gZLoLITX4nL9iweF7P5Ygp6PInGG475KhLH2QAIBZAIBAjApBgNVHSUEIjAgBggrBgEFBQcDAgYI KwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEFBQcDAjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AXDBV3ZWcwMjIxQGFk LnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMB0GA1UdDgQWBBT+Zrje5GhB Mi9c82Lx0F6vsUDFkzAfBgNVHSMEGDAWgBQBjyVQLIY0m8F+kB/ZiDW1P68LiTCCAV4GA1UdHwSC AVUwggFRMIIBTaCCAUmgggFFhoHjbGRhcDovLy9DTj1TcHJpbnQlMjBOZXh0ZWwlMjBFbnRlcnBy aXNlJTIwSXNzdWluZyUyMDElMjBBdXRob3JpdHksQ049UFBLSVdDMDEsQ049Q0RQLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9YWQsREM9 c3ByaW50LERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnSGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJ V0MwMS5jcmyGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNy bDCBhQYIKwYBBQUHAQEEeTB3MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5jb20vUFBL SVdDMDEvUFBLSVdDMDEuY3J0MDwGCCsGAQUFBzAChjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNv bS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwDQYJKoZIhvcNAQEFBQADggEBACKBUlCzudTCADaWm6ne dkIhMvaE1NtHnK5FRgc3xa9X5dMGtU3Oy7nHi2h589Fpc261zg0BGHtyomKL9C8enY3Uk6V7gHKR g3XPjXywKwzEVXwz1hrFuPd6EtH9RcDucLexumz1pcgpeSn7zjpVrHcJUmAD33xiKz62JdfE0W+G 6yVKZJhnmk9KCFCw4C6/tLljNPCqAykOsyG9XQYxVbP2599FPN+cDH1cIi6t6f5TITZdI/qgzqWo qAhzYlAjYFMZntw2vVGMOgpVrhjL5CX+1ke+03RfIIcYuTR+yoNI1KQ9p+rVvpnOGAOk2L9vhQf1 zQpKl+qa1nE2heTm0PoxggMhMIIDHQIBATCBhjB4MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYK CZImiZPyLGQBGRYGc3ByaW50MRIwEAYKCZImiZPyLGQBGRYCYWQxNTAzBgNVBAMTLFNwcmludCBO ZXh0ZWwgRW50ZXJwcmlzZSBJc3N1aW5nIDEgQXV0aG9yaXR5AgpILDrNAAAANdzuMAkGBSsOAwIa BQCgggHwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUxODE4 NDQwMlowIwYJKoZIhvcNAQkEMRYEFN49CmbhdlR+4AkqxrTUp0kVrrtwMFsGCSqGSIb3DQEJDzFO MEwwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMIGXBgkrBgEEAYI3EAQxgYkwgYYweDETMBEGCgmSJomT8ixk ARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYD VQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAA ADXc7jCBmQYLKoZIhvcNAQkQAgsxgYmggYYweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmS JomT8ixkARkWBnNwcmludDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4 dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1dGhvcml0eQIKSCw6zQAAADXc7jANBgkqhkiG9w0B AQEFAASBgLHRL4erQTMX1a3hPSANq+NMhxeFv22GhswNN+hENTJK4EcxMC06pQByf3TB+Pt0zcqS u/P6dyVP88KG0XgNGySqIhn70MqTHzEbfjiP3zzj7yJla/k28+hWINbTEqcrrDUNQcIKmBDz6oYu H0F+BbDaGALX5BRw3rZOtitro1emAAAAAAAA ------=_NextPart_000_011A_01CC156A.07AFF330-- From br.silvestre@gmail.com Tue May 17 12:00: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 0BC7FE07A2 for ; Tue, 17 May 2011 12:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 HvEJfZ0iIZCp for ; Tue, 17 May 2011 12:00:56 -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 A70DBE0780 for ; Tue, 17 May 2011 12:00:29 -0700 (PDT) Received: by vws12 with SMTP id 12so699905vws.31 for ; Tue, 17 May 2011 12:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=sZtw2lXzG89yHKPLz4DRe6JPbjPAMsy3FhYdiKsDeIk=; b=j8coJV2Y+ExFs7EIDHJIY+kqWtb+p3wQzc4gaQlK+phNgC+NktWoC+0PXPGKzSb5uA ujPw4/EkQSZpbmhm837nBnqYFAMGEp7LWKWQxN35kPiqezh967Nt3HNqedbhEQj/RL08 kcCYFwQYt9mLBqJYtdK2K+ta9EAvxJfLnVnVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=JGCEYfOVGngsofqWdl/RmFKZOdjvO58ZE/GeJxetyzYg3s0EXeXtcW8o7nJDo+h8dd /iRHgZ9R5FusYqfCNHTC020kJEG58TVqQGI2+jQCa76yCsz74JB7QdSPW65YmICck7sn O3O/LCOYp5y871bQ2rOJ54zAA0LaFZHawkOk0= MIME-Version: 1.0 Received: by 10.52.0.69 with SMTP id 5mr1326133vdc.96.1305658828585; Tue, 17 May 2011 12:00:28 -0700 (PDT) Received: by 10.52.101.167 with HTTP; Tue, 17 May 2011 12:00:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 17 May 2011 20:00:28 +0100 Message-ID: Subject: Fwd: DNS configuration for Wireless networks using Router Advertisement From: Bruno Silvestre To: ipv6@ietf.org, 20101130062720.280CDE06EF@rfc-editor.org Content-Type: multipart/alternative; boundary=20cf304346fead106a04a37d62b6 X-Mailman-Approved-At: Wed, 18 May 2011 12:33:49 -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, 17 May 2011 19:03:08 -0000 --20cf304346fead106a04a37d62b6 Content-Type: text/plain; charset=ISO-8859-1 Good Afternoon, I am currently developping an IPv6 project for University purposes for wireless networks and mobile devices. We configured radvd (router advertisement) to advertise a prefix in order to enable the AutoConfiguration of the hosts. This process works fine. However, we encounter problems to advertise DNS configuration. In fact, it seems that Android devices ( SDK 2.2 and 2.3 mobile phones) do not support DHCPv6, and so we should advertise the DNS configuration (DNS servers) by using Router Advertisement ?? According the RFC6106, this should be possible... But it seems that 'radvd' ignores the RDNSS and DNSSL options... We are running 'radvd' under Ubuntu Server. Is there any way to advertise the DNS configuration via Router Advertisement with radvd ? Do you know about some 'radvd' version, which can run these configurations for Ubuntu Server ? We are currently running radvd 1.6. Thank you very much in advance, Bruno P.S: Here comes our radvd.conf file: #radvd.conf *interface eth1 { AdvSendAdvert on; AdvManagedFlag off; AdvOtherConfigFlag off; prefix 2001:690:2060::/64 { AdvOnLink on; AdvAutonomous on; };* * * *# Advertise DNS server ??* *RDNSS 2001:690:2060::2 { AdvRDNSSPreference 8; AdvRDNSSOpen off; AdvRDNSSLifetime 3600; }; };* --20cf304346fead106a04a37d62b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Good Afternoon,

I am curr= ently developping an IPv6 project for University purposes for wireless netw= orks and mobile devices.

We configured radvd (rout= er advertisement) to advertise a prefix in order to enable the AutoConfigur= ation of the hosts.

This process works fine.

Howev= er, we encounter problems to advertise DNS configuration.

In fact, it seems that Android devices ( SDK 2.2 and 2.3 mobile pho= nes) do not support DHCPv6, and so we should advertise the DNS configuratio= n (DNS servers) by using Router Advertisement ??

According the RFC6106, this should be possible...
=

But it seems that 'radvd' ignores the RDNSS and= DNSSL options...

We are running 'radvd' u= nder Ubuntu Server.

Is there any way to advertise the DNS configuration via= Router Advertisement with radvd ?
Do you know about some 'ra= dvd' version, which can run these configurations for Ubuntu Server ?
We are currently running radvd 1.6.=A0

Thank = you very much in advance,

Bruno

P.S: Here comes our radvd.conf file:

#radvd.conf

interface eth1
{
    AdvSendAdvert on;
    AdvManagedFlag off;
    AdvOtherConfigFlag off;
    prefix 2001:690:2060::/64
  {
       AdvOnLink on;
       AdvAutonomous on;
  };

# Advertise DNS server ??
RDNSS 2001:690:2060::2
{
        AdvRDNSSPreference 8;
        AdvRDNSSOpen off;
        AdvRDNSSLifetime 3600;
};
};



=

--20cf304346fead106a04a37d62b6-- From pjeong@Brocade.com Wed May 18 11:21:38 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 16B5FE0766 for ; Wed, 18 May 2011 11:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 vRtifix28kFE for ; Wed, 18 May 2011 11:21:37 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC08E072C for ; Wed, 18 May 2011 11:21:36 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p4IIBQHb029682; Wed, 18 May 2011 11:21:33 -0700 Received: from brm-exedge.brocade.com (brm-exedge.brocade.com [144.49.197.7]) by mx0a-000f0801.pphosted.com with ESMTP id wcjjd010t-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 May 2011 11:21:33 -0700 Received: from brm-excashub-1.corp.brocade.com (172.16.72.131) by BRM-EXEDGE-1.corp.brocade.com (172.16.72.149) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 18 May 2011 12:21:24 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.1.145]) by brm-excashub-1.corp.brocade.com ([172.16.72.131]) with mapi; Wed, 18 May 2011 12:21:32 -0600 From: Jaehoon Jeong To: Bruno Silvestre , "jaehoon.paul@gmail.com" Date: Wed, 18 May 2011 12:21:30 -0600 Subject: RE: DNS configuration for Wireless networks using Router Advertisement Thread-Topic: DNS configuration for Wireless networks using Router Advertisement Thread-Index: AcwVh9M3yEDNuYlqT/OJ4mkIfzicdQAAIwLw Message-ID: <4D34E914CE7A004D8570F4381FDE5549A4DE49EA@BRM-EXCH-3.corp.brocade.com> References: In-Reply-To: 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_4D34E914CE7A004D8570F4381FDE5549A4DE49EABRMEXCH3corpbro_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.148, 0.0.0000 definitions=2011-05-18_03:2011-05-18, 2011-05-17, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1105180117 X-Mailman-Approved-At: Wed, 18 May 2011 12:33:49 -0700 Cc: Nuno Veiga , "ipv6@ietf.org" , "soohong.park@samsung.com" , Carlos 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, 18 May 2011 18:21:38 -0000 --_000_4D34E914CE7A004D8570F4381FDE5549A4DE49EABRMEXCH3corpbro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bruno, Thanks for this information. Best Regards, Paul From: Bruno Silvestre [mailto:br.silvestre@gmail.com] Sent: Wednesday, May 18, 2011 1:17 PM To: jaehoon.paul@gmail.com Cc: soohong.park@samsung.com; smadanapalli@gmail.com; Jaehoon Jeong; Carlos= ; Nuno Veiga; ipv6@ietf.org Subject: Re: DNS configuration for Wireless networks using Router Advertise= ment Dear All ! We found the solution of the problem. There was a problem in the clients side and not in the 'radvd' service. In fact, 'Windows 7 and Vista' clients do not consider the RDNSS option adv= ertised by radvd. In linux clients like Ubuntu 10.04, we installed a daemon to solve this. In Ubuntu 11.04, there is no need to install any daemon. For windows 7 and Vista, we had to install a program called 'rdnssd_win32',= which is an implementation of the RFC 6106 for Microsoft Windows. It parse= s the RDNSS options present in Router Advertisement (RA), get the DNS names= ervers and write them in the registry. Many thanks for your support, Bruno. 2011/5/17 Bruno Silvestre > Dear Mr. Jeong, I am currently developping an IPv6 project for University purposes for wire= less networks and mobile devices. We configured radvd (router advertisement) to advertise a prefix in order t= o enable the AutoConfiguration of the hosts. This process works fine. However, we encounter problems to advertise DNS configuration. In fact, it seems that Android devices ( SDK 2.2 and 2.3 mobile phones) do = not support DHCPv6, and so we should advertise the DNS configuration (DNS s= ervers) by using Router Advertisement ?? According the RFC6106, this should be possible... But it seems that 'radvd' ignores the RDNSS and DNSSL options... We are running 'radvd' under Ubuntu Server. Is there any way to advertise the DNS configuration via Router Advertisemen= t with radvd ? Do you know about some 'radvd' version, which can run these configurations = for Ubuntu Server ? We are currently running radvd 1.6. Thank you very much in advance, Bruno P.S: Here comes our radvd.conf file: #radvd.conf interface eth1 { AdvSendAdvert on; AdvManagedFlag off; AdvOtherConfigFlag off; prefix 2001:690:2060::/64 { AdvOnLink on; AdvAutonomous on; }; # Advertise DNS server ?? RDNSS 2001:690:2060::2 { AdvRDNSSPreference 8; AdvRDNSSOpen off; AdvRDNSSLifetime 3600; }; }; --_000_4D34E914CE7A004D8570F4381FDE5549A4DE49EABRMEXCH3corpbro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bruno,

Thanks for this information.=

 <= /p>

Best Regards,

Paul

<= o:p> 

From: Bruno Silvestr= e [mailto:br.silvestre@gmail.com]
Sent: Wednesday, May 18, 2011 = 1:17 PM
To: jaehoon.paul@gmail.com
Cc: soohong.park@sam= sung.com; smadanapalli@gmail.com; Jaehoon Jeong; Carlos; Nuno Veiga; ipv6@i= etf.org
Subject: Re: DNS configuration for Wireless networks usin= g Router Advertisement

 

Dear All !

 

We found= the solution of the problem.

 

There was a problem i= n the clients side and not in the 'radvd' service.

 

= In fact, 'Windows 7 and Vista' clients do not consider the RDNSS option adv= ertised by radvd.

 =

In linux clients like Ubuntu 10.0= 4, we installed a daemon to solve this.

In Ubuntu 11.04, there is no need to install any daemon.<= /o:p>

 

For windows 7 and Vista, we had to install a program cal= led 'rdnssd_win32', which is an implementation of the RFC 6106 for Mic= rosoft Windows. It parses the RDNSS options present in Router Advertis= ement (RA), get the DNS nameservers and write them in the registry.

 

Many thanks for your support,

 

Bruno.

2= 011/5/17 Bruno Silvestre <br.s= ilvestre@gmail.com>

Dear Mr. Jeon= g,

 

=

I am currently developping an IPv6 project for Univers= ity purposes for wireless networks and mobile devices.

=

 

We configured radvd (router advertisement) to advertise a prefix in ord= er to enable the AutoConfiguration of the hosts.

<= p class=3DMsoNormal> 

Th= is process works fine.

&= nbsp;

However, we encounter proble= ms to advertise DNS configuration.

 

In fact, it seem= s that Android devices ( SDK 2.2 and 2.3 mobile phones) do not support DHCP= v6, and so we should advertise the DNS configuration (DNS servers) by using= Router Advertisement ??

 

According the RFC6106, thi= s should be possible...

=  

But it seems that 'radvd' i= gnores the RDNSS and DNSSL options...

 

We are runnin= g 'radvd' under Ubuntu Server.

 

Is there any way to = advertise the DNS configuration via Router Advertisement with radvd ?<= /o:p>

Do you know about some 'radvd' ver= sion, which can run these configurations for Ubuntu Server ?

=

We are currently running radvd 1.6. 

 

Thank you very much in advance,

=

 

Bruno

 

P.S: Here comes our radvd.conf file:=

 

<= pre style=3D'white-space:pre-wrap'> 
#radvd.conf<=
o:p>
 
interface eth1
{
    AdvSen=
dAdvert on;
    AdvManagedFlag o=
ff;
    AdvOtherConfigFlag off;<=
o:p>
    prefix 2001:690:2060::/64
  {
  =
     AdvOnLink on;
 &n=
bsp;     AdvAutonomous on;
=
  };
&nbs=
p;
# Advertise DNS server=
 ??
RDNSS 2001:6=
90:2060::2
{
 =
       AdvRDNSSPreference 8;
        AdvRDNSSOpen off;
        AdvRDN=
SSLifetime 3600;
};
};

 

 

 

 

= --_000_4D34E914CE7A004D8570F4381FDE5549A4DE49EABRMEXCH3corpbro_-- From brian.e.carpenter@gmail.com Wed May 18 15:24:24 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 4C347E07E7 for ; Wed, 18 May 2011 15:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.583 X-Spam-Level: X-Spam-Status: No, score=-103.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 bwQCH6NapThn for ; Wed, 18 May 2011 15:24:23 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5DB4E0790 for ; Wed, 18 May 2011 15:24:23 -0700 (PDT) Received: by pwi5 with SMTP id 5so1295547pwi.31 for ; Wed, 18 May 2011 15:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vkUsLLOEtkdQ0V+mmMuKc5tg/0UJcjhe1Q3NGwiRCcE=; b=C7u6Phs6F0PhiUEKqUgRYX9GcrfRkwjotmsMOTZnHQ4dcpCD16Plh9KkPKUIdJQ+Ug E/J0WyPtWDohYfniel2cOXtUtC8Kk6FWYjsNykq7EW1EKvxkBuxdbSKQxqjrsx/A1Fp/ oVmKx8rkcTfzzTemS0JvAy90BVySTtohi0oqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=buIsTTWlZ1j3f/1dRi53NcE/kurY4QCY42x6w2tPSqAvlqWJOWhwdkt2FW4qVP3l9V 2OJgFIhTOl4TqWmaEN8myiny0WwYKf/ZKGd6WBIBo3LZzXHP2nyiXzY/yqAWNBpaRFHU LdO0TUK1KDNoKyVwDeOgTAnp7NteiKLtG3XQA= Received: by 10.142.163.7 with SMTP id l7mr1300401wfe.350.1305757463387; Wed, 18 May 2011 15:24:23 -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 k6sm1738321wfa.17.2011.05.18.15.24.21 (version=SSLv3 cipher=OTHER); Wed, 18 May 2011 15:24:22 -0700 (PDT) Message-ID: <4DD446F4.6000904@gmail.com> Date: Thu, 19 May 2011 10:23:48 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Haberman Subject: Re: Consensus call on adopting: draft-hartmann-6man-addressnaming References: <4DD40582.40005@innovationslab.net> In-Reply-To: <4DD40582.40005@innovationslab.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 WG 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: Wed, 18 May 2011 22:24:24 -0000 This draft claims to solve a problem that I don't have. BTW, we already have a name, in the normative ABNF in RFC 3986: h16 = 1*4HEXDIG ; 16 bits of address represented in hexadecimal (In the faulty ABNF of RFC 3261, it was called a hex4.) Regards Brian Carpenter On 2011-05-19 05:44, Brian Haberman wrote: > All, > This starts a 2-week consensus call on adopting: > > Title : Naming IPv6 address parts > Author(s) : L. Donnerhacke, et al. > Filename : draft-hartmann-6man-addresspartnaming-01.txt > Pages : 8 > Date : 2011-05-06 > > as a 6MAN WG document. Please state your opinion (either for or > against) on making this draft a WG draft either on the mailing list or > to the chairs. This call will end on May 1, 2011. > > Regards, > Brian & Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From ggm+ietf@apnic.net Wed May 18 15:50: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 E6D67E07A9 for ; Wed, 18 May 2011 15:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.746 X-Spam-Level: X-Spam-Status: No, score=-99.746 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] 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 LsmJg8USipUC for ; Wed, 18 May 2011 15:50:29 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 1C29FE0674 for ; Wed, 18 May 2011 15:50:27 -0700 (PDT) Received: from dynamic209.apnic.net (dynamic209.apnic.net [203.119.42.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 58D7FB68CA for ; Thu, 19 May 2011 08:50:25 +1000 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: Adapting draft-hartmann-6man-addresspartnaming as a WG item From: George Michaelson In-Reply-To: <4DD40BBA.6080507@gmail.com> Date: Thu, 19 May 2011 08:50:25 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <20CC4FA8-362A-4BB5-9CF2-846D18EE3321@apnic.net> References: <4DD40BBA.6080507@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1084) 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, 18 May 2011 22:50:30 -0000 This document doesn't recognise the reality of how language and names = develop. This area is something which is best left to be 'standardised' after the = fact, once the community has already decided what it calls the = address/parts. We are not the 'Academie Franciais' -There is no work for the IETF to do = here. I do not support adoption of this draft, or work in this area at this = time. -G= From albert.e.manfredi@boeing.com Wed May 18 17:54:14 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 5B767E06F3 for ; Wed, 18 May 2011 17:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 bd6Ub7PQBXAV for ; Wed, 18 May 2011 17:54:13 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id D164BE06EC for ; Wed, 18 May 2011 17:54:13 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4J0rwWu002384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 May 2011 17:54:00 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p4J0rvOm026870; Wed, 18 May 2011 17:53:57 -0700 (PDT) Received: from XCH-MWHT-05.mw.nos.boeing.com (xch-mwht-05.mw.nos.boeing.com [134.57.119.160]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4J0rviv026851 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 18 May 2011 17:53:57 -0700 (PDT) Received: from XCH-MWHT-07.mw.nos.boeing.com (134.57.118.77) by XCH-MWHT-05.mw.nos.boeing.com (134.57.119.160) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 18 May 2011 19:53:57 -0500 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-07.mw.nos.boeing.com ([134.57.118.77]) with mapi; Wed, 18 May 2011 19:53:56 -0500 From: "Manfredi, Albert E" To: George Michaelson , "ipv6@ietf.org" Date: Wed, 18 May 2011 19:53:52 -0500 Subject: RE: Adapting draft-hartmann-6man-addresspartnaming as a WG item Thread-Topic: Adapting draft-hartmann-6man-addresspartnaming as a WG item Thread-Index: AcwVrgwV+M+WzNBRQquOR0Ll5fJQ3AAEFTkQ Message-ID: References: <4DD40BBA.6080507@gmail.com> <20CC4FA8-362A-4BB5-9CF2-846D18EE3321@apnic.net> In-Reply-To: <20CC4FA8-362A-4BB5-9CF2-846D18EE3321@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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, 19 May 2011 00:54:14 -0000 George Michaelson wrote: > This document doesn't recognise the reality of how language and names > develop. >=20 > This area is something which is best left to be 'standardised' after > the fact, once the community has already decided what it calls the > address/parts. >=20 > We are not the 'Academie Franciais' -There is no work for the IETF to > do here. >=20 > I do not support adoption of this draft, or work in this area at this > time. Spelling of Acad=E9mie Fran=E7aise aside, I had precisely the same thought = when this discussion began. (Although it was fun to hear others make their = own suggestions.) +1 Bert From i.grok@comcast.net Wed May 18 21:14:24 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 668C4E06C8 for ; Wed, 18 May 2011 21:14:24 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhbuAR8oBXjk for ; Wed, 18 May 2011 21:14:23 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9468CE0674 for ; Wed, 18 May 2011 21:14:23 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA11.westchester.pa.mail.comcast.net with comcast id lG9u1g00217dt5G5BGEQpQ; Thu, 19 May 2011 04:14:24 +0000 Received: from odin.ulthar.us ([68.33.77.0]) by omta13.westchester.pa.mail.comcast.net with comcast id lGEP1g00M00PQ6U3ZGEPmK; Thu, 19 May 2011 04:14:24 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.4/8.14.3) with ESMTP id p4J4EM8L009370 for ; Thu, 19 May 2011 00:14:22 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.14.4/8.14.4/Submit) id p4J4ELE5009368 for ipv6@ietf.org; Thu, 19 May 2011 00:14:21 -0400 Date: Thu, 19 May 2011 00:14:21 -0400 From: Scott Schmit To: ipv6@ietf.org Subject: Re: Consensus call on adopting: draft-hartmann-6man-addressnaming Message-ID: <20110519041421.GA9323@odin.ulthar.us> Mail-Followup-To: ipv6@ietf.org References: <4DD40582.40005@innovationslab.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD40582.40005@innovationslab.net> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 19 May 2011 04:14:24 -0000 On Wed, May 18, 2011 at 01:44:34PM -0400, Brian Haberman wrote ipv6: > All, > This starts a 2-week consensus call on adopting: > > Title : Naming IPv6 address parts > Author(s) : L. Donnerhacke, et al. > Filename : draft-hartmann-6man-addresspartnaming-01.txt > Pages : 8 > Date : 2011-05-06 > > as a 6MAN WG document. Please state your opinion (either for or > against) on making this draft a WG draft either on the mailing list or > to the chairs. This call will end on May 1, 2011. ^^^ June? I do not support adoption of this draft, as I don't believe that it is a real problem--if it were, we wouldn't need to choose a name for the parts--we'd already have one. -- Scott Schmit From randy@psg.com Fri May 20 06:06: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 3AD82E06F7 for ; Fri, 20 May 2011 06:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 sghm5XLlLIiS for ; Fri, 20 May 2011 06:06:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [147.28.0.36]) by ietfa.amsl.com (Postfix) with ESMTP id 5B88BE0684 for ; Fri, 20 May 2011 06:06:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.local.psg.com) by ran.psg.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QNPOF-000CnT-ID; Fri, 20 May 2011 13:05:16 +0000 Date: Fri, 20 May 2011 15:05:14 +0200 Message-ID: From: Randy Bush To: Scott Schmit Subject: Re: Consensus call on adopting: draft-hartmann-6man-addressnaming In-Reply-To: <20110519041421.GA9323@odin.ulthar.us> References: <4DD40582.40005@innovationslab.net> <20110519041421.GA9323@odin.ulthar.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII 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, 20 May 2011 13:06:35 -0000 >> This starts a 2-week consensus call on adopting: >> Title : Naming IPv6 address parts >> Author(s) : L. Donnerhacke, et al. >> Filename : draft-hartmann-6man-addresspartnaming-01.txt to be my usual tactful self, i find this an embarrassment. it ranks right up there with a multi-month discussion of a dot in an AS number. so no, i do not support it. randy From huitema@microsoft.com Sat May 21 21:04: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 8F15EE0711 for ; Sat, 21 May 2011 21:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 9AsMoQUA9f9r for ; Sat, 21 May 2011 21:03:59 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id CD702E06B7 for ; Sat, 21 May 2011 21:03:59 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 21 May 2011 21:03:59 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.1.289.8; Sat, 21 May 2011 21:03:58 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.58]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Sat, 21 May 2011 21:03:59 -0700 From: Christian Huitema To: Brian Haberman , IPv6 WG Mailing List Subject: RE: Consensus call on adopting: draft-hartmann-6man-addressnaming Thread-Topic: Consensus call on adopting: draft-hartmann-6man-addressnaming Thread-Index: AQHMFYNYpie2G8BfmkORfrXFXoNvw5SYPnTA Date: Sun, 22 May 2011 04:03:57 +0000 Message-ID: <22F6318E46E26B498ABC828879B08D4F155A52@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> References: <4DD40582.40005@innovationslab.net> In-Reply-To: <4DD40582.40005@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Sun, 22 May 2011 04:04:00 -0000 > This starts a 2-week consensus call on adopting ... > draft-hartmann-6man-addresspartnaming-01.txt > as a 6MAN WG document. Please state your opinion (either for or > against) on making this draft a WG draft either on the mailing list or to= the chairs. This call will end on May 1, 2011. I do not support adoption of this document as a work item. There is no pres= sing problem to solve there. The working group has more urgent work to do t= han wasting time on this subject, and we really don't need to impose some "= name correctness tax" on the authors of future drafts. -- Christian Huitema From yhb810501@gmail.com Sun May 22 04:34:25 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 0DA47E0658 for ; Sun, 22 May 2011 04:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] 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 ImEYcuxMYdnr for ; Sun, 22 May 2011 04:34:22 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1E581E0655 for ; Sun, 22 May 2011 04:34:21 -0700 (PDT) Received: by pxi2 with SMTP id 2so3001217pxi.38 for ; Sun, 22 May 2011 04:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:references:in-reply-to :subject:date:mime-version:content-type:content-transfer-encoding :x-priority:x-msmail-priority:importance:x-mailer:x-mimeole; bh=eGrLn/JCNgcdETU6Vk7IamQR+kPrFhLBOsjSPT8+pSI=; b=bun78z/UGbMlXtbPX1n0JZiA+fgyQMlAu6Bi6DZpwL4jmokd6ntynp3j08XcWDa/UQ Oj50l49red/uiHCT8F8ghDLs+ESTbvQ8ze+3QYFGsS2YXI3sOzzuOKdcMyFe7a6jwpok xzocHft7LG14zCBDi0sshIUgYLTWH4iDFfHVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :importance:x-mailer:x-mimeole; b=pVrleESsqM92Dbq3C+SzcR3s8xoQDhfpPCM+rJECMZgoSq/+k6f7k9R4ZQz6G9vx2W 8QzYOaoR5V23yF+mIPFHCC/E7XbjPMfTBUIIq6lh3UQ8j6xypfYf+CsQ9PUqrEtW+IHq waKVvpmP7fImIZ6XsRP9cfVz+HD4jRQePe914= Received: by 10.142.247.7 with SMTP id u7mr670998wfh.255.1306064061674; Sun, 22 May 2011 04:34:21 -0700 (PDT) Received: from yhbPC ([175.42.41.14]) by mx.google.com with ESMTPS id k4sm3673731pbi.77.2011.05.22.04.34.17 (version=SSLv3 cipher=OTHER); Sun, 22 May 2011 04:34:20 -0700 (PDT) Message-ID: <4B9C8A32731A42C188803715C07EA639@yhbPC> From: "Yu Hua bing" To: "Brian Haberman" , "IPv6 WG Mailing List" References: <4DD40582.40005@innovationslab.net> <22F6318E46E26B498ABC828879B08D4F155A52@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <22F6318E46E26B498ABC828879B08D4F155A52@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> Subject: Re: Consensus call on adopting: draft-hartmann-6man-addressnaming Date: Sun, 22 May 2011 19:34:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 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, 22 May 2011 11:34:25 -0000 I do not support this draft too. -------------------------------------------------- From: "Christian Huitema" Sent: Sunday, May 22, 2011 12:03 PM To: "Brian Haberman" ; "IPv6 WG Mailing List" Subject: RE: Consensus call on adopting: draft-hartmann-6man-addressnaming >> This starts a 2-week consensus call on adopting ... >> draft-hartmann-6man-addresspartnaming-01.txt >> as a 6MAN WG document. Please state your opinion (either for or >> against) on making this draft a WG draft either on the mailing list or to >> the chairs. This call will end on May 1, 2011. > > I do not support adoption of this document as a work item. There is no > pressing problem to solve there. The working group has more urgent work to > do than wasting time on this subject, and we really don't need to impose > some "name correctness tax" on the authors of future drafts. > > -- Christian Huitema > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From internet-drafts@ietf.org Mon May 23 09:12: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 DC12EE0776; Mon, 23 May 2011 09:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 LeE++VZ-EF5N; Mon, 23 May 2011 09:12:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2DDE0787; Mon, 23 May 2011 09:12:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-node-req-bis-10.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110523161239.5901.5184.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2011 09:12:39 -0700 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, 23 May 2011 16:12:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : IPv6 Node Requirements Author(s) : Ed Jankiewicz John Loughney Thomas Narten Filename : draft-ietf-6man-node-req-bis-10.txt Pages : 31 Date : 2011-05-23 This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC4294. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-10.txt From narten@us.ibm.com Mon May 23 09:18: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 195FDE0686 for ; Mon, 23 May 2011 09:18:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib7v72ZELknE for ; Mon, 23 May 2011 09:18:33 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id 67A22E0684 for ; Mon, 23 May 2011 09:18:33 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e31.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4NG1sib007292 for ; Mon, 23 May 2011 10:01:54 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4NGI7Qi149328 for ; Mon, 23 May 2011 10:18:12 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4NAI60N019455 for ; Mon, 23 May 2011 04:18:06 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-221-88.mts.ibm.com [9.65.221.88]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4NAI5WT019376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 May 2011 04:18:06 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4NGI4sk010943 for ; Mon, 23 May 2011 12:18:04 -0400 Message-Id: <201105231618.p4NGI4sk010943@cichlid.raleigh.ibm.com> To: ipv6@ietf.org Subject: Re: I-D Action: draft-ietf-6man-node-req-bis-10.txt In-reply-to: <20110523161239.5901.5184.idtracker@ietfa.amsl.com> References: <20110523161239.5901.5184.idtracker@ietfa.amsl.com> Comments: In-reply-to internet-drafts@ietf.org message dated "Mon, 23 May 2011 09:12:39 -0700." Date: Mon, 23 May 2011 12:18:04 -0400 From: Thomas Narten 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, 23 May 2011 16:18:34 -0000 WG, I believe this version is ready to advance to the IESG. >From the changes section: > 17.1. Appendix: Changes from -09 to -10 > > 1. With changes in requirements for IPsec and Routing Headers, > clarified language regarding processing of unknown options, and > removed paragraph lising which extension headers were required to > be implemented. Above changes are in Section 5.1. > 2. Removed "RFC4292-bis" from title. > 3. Expanded the text on Jumbograms. > 4. Changed recommendation of DHCPv6 from MAY to SHOULD. > 5. Expanded the text on RFC4191, and changed recommendation from MAY > to SHOULD. The last 3 changes have recently been discussed on the mailing list. Thomas From nordmark@acm.org Mon May 23 11:46: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 924A7E07E6 for ; Mon, 23 May 2011 11:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 qDNp-lJ47xf8 for ; Mon, 23 May 2011 11:46:36 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 57FFFE0707 for ; Mon, 23 May 2011 11:46:34 -0700 (PDT) Received: from [128.107.115.154] ([128.107.115.154]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p4NIkUWQ008381 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 23 May 2011 11:46:31 -0700 Message-ID: <4DDAAB85.8000103@acm.org> Date: Mon, 23 May 2011 11:46:29 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Neighbor Unreachability Detection is too impatient Content-Type: text/plain; charset=UTF-8; format=flowed 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: Mon, 23 May 2011 18:46:36 -0000 This draft proposes to change the requirement that NUD can not retransmit more than three times, so that NUD can be more robust against temporary network outages. Comments? Erik -------- Original Message -------- Subject: New Version Notification for draft-nordmark-6man-impatient-nud-00.txt Date: Mon, 23 May 2011 11:43:16 -0700 From: internet-drafts@ietf.org To: nordmark@cisco.com CC: nordmark@cisco.com A new version of I-D, draft-nordmark-6man-impatient-nud-00.txt has been successfully submitted by Erik Nordmark and posted to the IETF repository. Filename: draft-nordmark-6man-impatient-nud Revision: 00 Title: Neighbor Unreachability Detection is too impatient Creation date: 2011-05-23 WG ID: Individual Submission Number of pages: 5 Abstract: IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative, for instance multiple default routers, since it allows the host to switch to the alternative in short time. This time is 3 seconds after the node starts probing. However, if there are no alternatives, this is far too impatient. This document proposes an approach where an implementation can choose the timeout behavior to be different based on whether or not there are alternatives. The IETF Secretariat From wbeebee@cisco.com Mon May 23 12:25: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 1F29FE081B for ; Mon, 23 May 2011 12:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.833 X-Spam-Level: X-Spam-Status: No, score=-7.833 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 fHKfUr9HzQKh for ; Mon, 23 May 2011 12:25:53 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 928A7E07DD for ; Mon, 23 May 2011 12:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=2068; q=dns/txt; s=iport; t=1306178753; x=1307388353; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=gW/LwTTzV08RARQXOKTjI2DyURhLH4NjW+ObhCKHdlU=; b=LyiaFsRCDbwzafLLRf2wY++QGUPzYB313ct4iGDfLYsLAzQVfuHQZz6Z 9H2wDduZALptphqHHYq98fp9bcc3mtXlf0keiAklf5yTJP/Y/7wt7SKDM z0w1Km1cGdh1KoGBIHkQX/3yg5T0twcFfo1l/vB7PdiRGtgB2xv0T65+/ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8GACK02k2tJV2b/2dsb2JhbACmJQJ3iHCfAJ1UhhkEkBGEOIZrg24 X-IronPort-AV: E=Sophos;i="4.65,258,1304294400"; d="scan'208";a="452814131" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-1.cisco.com with ESMTP; 23 May 2011 19:25:53 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4NJPqEj015394; Mon, 23 May 2011 19:25:53 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 May 2011 14:25:52 -0500 Received: from 161.44.175.134 ([161.44.175.134]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 May 2011 19:25:52 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Mon, 23 May 2011 15:25:51 -0400 Subject: Re: Neighbor Unreachability Detection is too impatient From: Wes Beebee To: Erik Nordmark , Message-ID: Thread-Topic: Neighbor Unreachability Detection is too impatient Thread-Index: AcwZfznoG/pikWbHzkeHDSnG13vA8w== In-Reply-To: <4DDAAB85.8000103@acm.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 May 2011 19:25:52.0863 (UTC) FILETIME=[3B050EF0:01CC197F] 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, 23 May 2011 19:25:55 -0000 Erik, I have seen NUD packets dropped during congestion, and for traffic to periodically drop out for re-resolution. I agree with the goal of making NUD more robust. However, there may be other approaches besides retransmitting more times. - Wes On 5/23/11 2:46 PM, "Erik Nordmark" wrote: > > This draft proposes to change the requirement that NUD can not > retransmit more than three times, so that NUD can be more robust against > temporary network outages. > > Comments? > > Erik > > -------- Original Message -------- > Subject: New Version Notification for > draft-nordmark-6man-impatient-nud-00.txt > Date: Mon, 23 May 2011 11:43:16 -0700 > From: internet-drafts@ietf.org > To: nordmark@cisco.com > CC: nordmark@cisco.com > > A new version of I-D, draft-nordmark-6man-impatient-nud-00.txt has been > successfully submitted by Erik Nordmark and posted to the IETF repository. > > Filename: draft-nordmark-6man-impatient-nud > Revision: 00 > Title: Neighbor Unreachability Detection is too impatient > Creation date: 2011-05-23 > WG ID: Individual Submission > Number of pages: 5 > > Abstract: > IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. > That function is very useful when a host has an alternative, for > instance multiple default routers, since it allows the host to switch > to the alternative in short time. This time is 3 seconds after the > node starts probing. However, if there are no alternatives, this is > far too impatient. This document proposes an approach where an > implementation can choose the timeout behavior to be different based > on whether or not there are alternatives. > > > > > > The IETF Secretariat > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From mark@townsley.net Mon May 23 12:47:42 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 7061EE083F for ; Mon, 23 May 2011 12:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=1.394, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 OIl5mRgXkRAS for ; Mon, 23 May 2011 12:47:41 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 18DD1E0840 for ; Mon, 23 May 2011 12:47:40 -0700 (PDT) Received: by wwa36 with SMTP id 36so4537962wwa.13 for ; Mon, 23 May 2011 12:47:40 -0700 (PDT) Received: by 10.217.6.14 with SMTP id x14mr2613227wes.32.1306180060128; Mon, 23 May 2011 12:47:40 -0700 (PDT) Received: from ams-townsley-8716.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id n2sm3453905wej.46.2011.05.23.12.47.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2011 12:47:26 -0700 (PDT) Subject: Re: Neighbor Unreachability Detection is too impatient Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-16--692171910 From: Mark Townsley In-Reply-To: <4DDAAB85.8000103@acm.org> Date: Mon, 23 May 2011 21:47:06 +0200 Message-Id: References: <4DDAAB85.8000103@acm.org> To: Erik Nordmark 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: Mon, 23 May 2011 19:47:42 -0000 --Apple-Mail-16--692171910 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Erik Kline and I wrote up an experience we had with NUD and a broken = IPv6 firewall on my home network. http://sites.google.com/site/ipv6center/icmpv6-is-non-optional In short, NUD thought that a host which was in the neighbor cache really = wasn't available (due to incorrect FW blocking at the host) removed it = from the neighbor cache and started dropping packets (and causing = timeouts in gmail). In test, it took about 8 pings for the problem to = manifest (time for NUD to retry enough to fail), which was followed by = the classic IPv6 to IPv4 failover by the host (Windows Vista).=20 On one hand, if NUD had been more patient we may have never noticed. = However, tracking down a bug that showed up less often would have = clearly been more difficult to diagnose. Double-edged sword. Also, the Broadband Forum's WT-146 (which isn't a public document, but = if you are BBF member you can take a look at it) specifies NUD as a = monitoring mechanism for "IPv6 sessions" over access links (which = ultimately may be tied into billing, alerts, etc.).=20 - Mark On May 23, 2011, at 8:46 PM, Erik Nordmark wrote: >=20 > This draft proposes to change the requirement that NUD can not = retransmit more than three times, so that NUD can be more robust against = temporary network outages. >=20 > Comments? >=20 > Erik >=20 > -------- Original Message -------- > Subject: New Version Notification for = draft-nordmark-6man-impatient-nud-00.txt > Date: Mon, 23 May 2011 11:43:16 -0700 > From: internet-drafts@ietf.org > To: nordmark@cisco.com > CC: nordmark@cisco.com >=20 > A new version of I-D, draft-nordmark-6man-impatient-nud-00.txt has = been successfully submitted by Erik Nordmark and posted to the IETF = repository. >=20 > Filename: draft-nordmark-6man-impatient-nud > Revision: 00 > Title: Neighbor Unreachability Detection is too = impatient > Creation date: 2011-05-23 > WG ID: Individual Submission > Number of pages: 5 >=20 > Abstract: > IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. > That function is very useful when a host has an alternative, for > instance multiple default routers, since it allows the host to = switch > to the alternative in short time. This time is 3 seconds after the > node starts probing. However, if there are no alternatives, this is > far too impatient. This document proposes an approach where an > implementation can choose the timeout behavior to be different based > on whether or not there are alternatives. >=20 >=20 >=20 >=20 > The IETF Secretariat > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail-16--692171910 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii ht= tp://sites.google.com/site/ipv6center/icmpv6-is-non-optional

In short, NUD thought that a host which was in the = neighbor cache really wasn't available (due to incorrect FW blocking at = the host) removed it from the neighbor cache and started dropping = packets (and causing timeouts in gmail). In test, it took about 8 pings = for the problem to manifest (time for NUD to retry enough to fail), = which was followed by the classic IPv6 to IPv4 failover by the host = (Windows Vista). 

On one hand, if NUD had = been more patient we may have never noticed. However, tracking down a = bug that showed up less often would have clearly been more difficult to = diagnose. Double-edged sword.

Also, the = Broadband Forum's WT-146 (which isn't a public document, but if you are = BBF member you can take a look at it)  specifies NUD as a = monitoring mechanism for "IPv6 sessions" over access links (which = ultimately may be tied into billing, alerts, = etc.). 

- = Mark



On May 23, 2011, = at 8:46 PM, Erik Nordmark wrote:


This draft proposes to change the requirement = that NUD can not retransmit more than three times, so that NUD can be = more robust against temporary network outages.

Comments?

=   Erik

-------- Original Message --------
Subject: = New Version Notification for = draft-nordmark-6man-impatient-nud-00.txt
Date: Mon, 23 May 2011 = 11:43:16 -0700
From: internet-drafts@ietf.org
T= o: nordmark@cisco.com
CC: = nordmark@cisco.com

A = new version of I-D, draft-nordmark-6man-impatient-nud-00.txt has been = successfully submitted by Erik Nordmark and posted to the IETF = repository.

Filename: = draft-nordmark-6man-impatient-nud
Revision: = 00
Title: = = Neighbor Unreachability Detection is too impatient
Creation = date: = 2011-05-23
WG ID: Individual Submission
Number = of pages: 5

Abstract:
  IPv6 Neighbor Discovery = includes Neighbor Unreachability Detection.
  That = function is very useful when a host has an alternative, for
=   instance multiple default routers, since it allows the host = to switch
  to the alternative in short time.  This = time is 3 seconds after the
  node starts probing. =  However, if there are no alternatives, this is
  far = too impatient.  This document proposes an approach where an
=   implementation can choose the timeout behavior to be = different based
  on whether or not there are = alternatives.




The IETF = Secretariat
-----------------------------------------------------------= ---------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative = Requests: = https://www.ietf.org/mailman/listinfo/ipv6
----------------------------= ----------------------------------------

<= /body>= --Apple-Mail-16--692171910-- From v6ops@globis.net Mon May 23 13:03: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 581D0E06D1 for ; Mon, 23 May 2011 13:03:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeUkUsth6HAr for ; Mon, 23 May 2011 13:03:56 -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 6E345E06B6 for ; Mon, 23 May 2011 13:03:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 343918700E3 for ; Mon, 23 May 2011 22:03:55 +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 bEKEZzDzjAYV for ; Mon, 23 May 2011 22:03:50 +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 7B5E8870030 for ; Mon, 23 May 2011 22:03:50 +0200 (CEST) Message-ID: <4DDABDA6.2070705@globis.net> Date: Mon, 23 May 2011 22:03:50 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: ipv6@ietf.org Subject: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Mon, 23 May 2011 20:03:57 -0000 re: http://tools.ietf.org/html/draft-nordmark-6man-impatient-nud-00 I'm afraid have more questions than answers. Are there any implications for different nodes having different NUD timeout behavior on a link, and this no longer being symmetrical? If I can think of two examples...... e.g. 1. Say Node A (router) declares node C (end node) unreachable but Node B (alternate back up router) has not yet timed out node C? I'm guessing this case is just like a split-brain segment, so is not significant compared to existing failures. Now the case of router failover.... e.g. 2. Say Node A (end host) declares node B (router) unreachable locally, but node B (router) is still up and running but has not yet timed out Node A. Is that significant? I suspect so. After all if the raison d'etre of changing NUD timers is to quicken / slow down router failover, surely Node B (the router) also has to time out at the same speed as the end host (Node A) otherwise the router will continue to advertise valid routes to node A, and packets will black hole/queue anyway until NUD on node B also notices the failure. Vice versa is also true, if the router notices the failure first, but the end node does not react to the failure and hangs around retrying NUD, packets may queue/black hole in the other direction. In the good old days we had things like gratuitous ARP for such events to attempt to wake up end nodes to refresh their cache, but if they got lost in some layer 2 STP thrashing it didn't help much anyway. Is there thus a need for any over-ridden NUD parameters to be synchronized across all nodes on a link e.g. via RA messages? Is there a minimum and maximum timeout needed? To prevent danger of an update storm [as specified in RFC2461 that all Neighbor Solicitations are rate-limited on a per-neighbor basis] or "stuck in stale". regards, RayH From narten@us.ibm.com Mon May 23 13:10:53 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 2C616E07EA for ; Mon, 23 May 2011 13:10:53 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 PqOzzShfbgte for ; Mon, 23 May 2011 13:10:52 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by ietfa.amsl.com (Postfix) with ESMTP id 151EAE07DB for ; Mon, 23 May 2011 13:10:52 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4NK3ZvW006503 for ; Mon, 23 May 2011 14:03:35 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4NKAjQj133962 for ; Mon, 23 May 2011 14:10:45 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4NEAdxX007088 for ; Mon, 23 May 2011 08:10:41 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-221-88.mts.ibm.com [9.65.221.88]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4NEAbKI006976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2011 08:10:38 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4NKAV9X012654; Mon, 23 May 2011 16:10:32 -0400 Message-Id: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> To: "Brzozowski, John" Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD In-reply-to: References: Comments: In-reply-to "Brzozowski, John" message dated "Sun, 15 May 2011 12:15:37 -0000." Date: Mon, 23 May 2011 16:10:31 -0400 From: Thomas Narten Cc: "ipv6@ietf.org" , Bob Hinden 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, 23 May 2011 20:10:53 -0000 > Is the intention for the new text to relax the requirement for > auto-configuration? No. SLAAC remains a MUST. DHCPv6 though is now a SHOULD. For one thing, DHCP doesn't have an option configure on-link prefixes, so we still need SLAAC. What we should have done oh-so-long-ago is ensure that you could configure/operate a network with just DHCP (and no SLAAC at all) and vice versa, and than made both a MUST on hosts. That way, operators truly have the choice as to which to use and everything would just work. Thomas From rdroms.ietf@gmail.com Mon May 23 13:21: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 97AD6E0833 for ; Mon, 23 May 2011 13:21:22 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUDiUoIQoGmx for ; Mon, 23 May 2011 13:21:21 -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 C5BF3E069A for ; Mon, 23 May 2011 13:21:21 -0700 (PDT) Received: by vxg33 with SMTP id 33so5270236vxg.31 for ; Mon, 23 May 2011 13:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=+K38kdb0EDweCXSBw6O/HKnB9h4oZOlQa45ClZ/PQeM=; b=gteOWRkQoPRf/NwedBAKw6M9NFenrmOnnfPqa6XcNQ2j1mvahPqjnvU8aNusGvm88/ rMdIeoMtafM+snyFASatLSNry3JUPof1VkooS8WQOy1sWfXqxG4sJUuoJJikDJ57iuSG ARvOxurKp9MjBRi5In/C28oRwHgngRKNlHK/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=bgAcAzF+V1GydcedbOX2MTFBhXxIXb4f9eVH9ubqLL3kXzCMmPqMiBTwVuNbKgJs5d Ugox1pWzl0Cu/e+0SXmWKCPtIc74Dd9btekBB646Oun8aSkIUyRoAMc0NGNp9DqDo7ou 2JOJkK2IyxVIXRvvGJ/TLZjrNLKMrHBZOfPdc= Received: by 10.52.100.70 with SMTP id ew6mr3583262vdb.95.1306182081274; Mon, 23 May 2011 13:21:21 -0700 (PDT) Received: from [161.44.65.177] ([161.44.65.177]) by mx.google.com with ESMTPS id dq2sm1415036vdc.19.2011.05.23.13.21.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2011 13:21:20 -0700 (PDT) Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> Date: Mon, 23 May 2011 16:21:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: Bob Hinden , "ipv6@ietf.org" , Ralph Droms 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, 23 May 2011 20:21:22 -0000 Thomas - (hoping to fan the discussion) I think operators have expressed = the desire to operate networks in DHCP-only mode, and the response has = been "No, you don't really want to operate your networks that way". If operators came forward again with a strong desire to operate networks = using only DHCP, and no other technical reason, would they get a = different answer today? - Ralph On May 23, 2011, at 4:10 PM 5/23/11, Thomas Narten wrote: >> Is the intention for the new text to relax the requirement for >> auto-configuration? >=20 > No. SLAAC remains a MUST. DHCPv6 though is now a SHOULD. >=20 > For one thing, DHCP doesn't have an option configure on-link prefixes, > so we still need SLAAC. >=20 > What we should have done oh-so-long-ago is ensure that you could > configure/operate a network with just DHCP (and no SLAAC at all) and > vice versa, and than made both a MUST on hosts. That way, operators > truly have the choice as to which to use and everything would just > work. >=20 > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From christopher.morrow@gmail.com Mon May 23 13:58:03 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 59C6EE06BC for ; Mon, 23 May 2011 13:58:03 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGhuVtAFPUdM for ; Mon, 23 May 2011 13:58:02 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 805B3E069A for ; Mon, 23 May 2011 13:58:02 -0700 (PDT) Received: by wwa36 with SMTP id 36so4581203wwa.13 for ; Mon, 23 May 2011 13:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NRF4nv/pp88xpyydv1WXcDW91dWvHLTKWR9BUl73/fk=; b=t4KmYOTro2xy2fc9SH9bbDu+//mIWmI/1mKXbkeSsAFAbsVyS7a07qe1aYbyZtS6UD p09TEUgOfFDix3P+pUljrmem4AK3MrUQYaXkAurkczyZDHVGPo79bElz9bKlEfs2Gj/w C7cTrvx3rJ8ZFaVPjFdl40LOkZQvORYTrm36w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FBEgNh3fUwWMK3eg9nO2bK6Z8Y9fjk/4O8nV6sKKLKabnXTQ9988irmsQLIsKjz91Z knt7p9W8D0MUfp1op3Tu5SxhBdXNe6JEu2ejDqaT0y+0fEP3YDykOYgkDPmJ0caqk2iJ N0B5Y/NY+/RAJaRUReiftQczKqgPU2j6XnwPM= MIME-Version: 1.0 Received: by 10.216.144.166 with SMTP id n38mr2623866wej.75.1306184281397; Mon, 23 May 2011 13:58:01 -0700 (PDT) Received: by 10.216.73.212 with HTTP; Mon, 23 May 2011 13:58:00 -0700 (PDT) In-Reply-To: <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> Date: Mon, 23 May 2011 16:58:00 -0400 Message-ID: Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: Christopher Morrow To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , "ipv6@ietf.org" , Bob Hinden 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, 23 May 2011 20:58:03 -0000 On Mon, May 23, 2011 at 4:21 PM, Ralph Droms wrote: > Thomas - (hoping to fan the discussion) I think operators have expressed = the desire to operate networks in DHCP-only mode, and the response has been= "No, you don't really want to operate your networks that way". > one gotcha with 'dhcp only' is perhaps folks mean: "slaac to signal v6 is on-net, but require full config from a dhcpv6 server". How does a host know that v6 is available otherwise? (this may be why someone said "you don't really want to do that..') -chris > If operators came forward again with a strong desire to operate networks = using only DHCP, and no other technical reason, would they get a different = answer today? > > - Ralph > > On May 23, 2011, at 4:10 PM 5/23/11, Thomas Narten wrote: > >>> Is the intention for the new text to relax the requirement for >>> auto-configuration? >> >> No. SLAAC remains a MUST. DHCPv6 though is now a SHOULD. >> >> For one thing, DHCP doesn't have an option configure on-link prefixes, >> so we still need SLAAC. >> >> What we should have done oh-so-long-ago is ensure that you could >> configure/operate a network with just DHCP (and no SLAAC at all) and >> vice versa, and than made both a MUST on hosts. =A0That way, operators >> truly have the choice as to which to use and everything would just >> work. >> >> Thomas >> -------------------------------------------------------------------- >> 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 v6ops@globis.net Mon May 23 14:10:28 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 F1F01E07F3 for ; Mon, 23 May 2011 14:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] 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 17adHoXyCpHR for ; Mon, 23 May 2011 14:10:28 -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 AEE5BE0838 for ; Mon, 23 May 2011 14:10:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E701F870083; Mon, 23 May 2011 23:10:26 +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 qv5KjmaavrIL; Mon, 23 May 2011 23:10:09 +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 D56E0870023; Mon, 23 May 2011 23:10:09 +0200 (CEST) Message-ID: <4DDACD31.9020602@globis.net> Date: Mon, 23 May 2011 23:10:09 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Philip Homburg Subject: Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080300060107060109000906" 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, 23 May 2011 21:10:29 -0000 This is a multi-part message in MIME format. --------------080300060107060109000906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Who says that NUD can't also be used to declare an interface down/ detect router neighbor loss? Maybe think of a BGP process running over TCP receiving ICMP unreachables because the local NUD has declared the neighbor unreachable. Meanwhile the other BGP partner router is still retrying at TCP layer because NUD has not timed out on that node. Or am I seeing non-existent links here? As someone who has had more than one evening / weekend ruined in a data centre with sniffers looking at interactions between ARP and STP thrashing about and Cisco HSRP and HP MC ServiceGuard and Network intrusion detection/ firewall failover, I would contend that these mechanisms are anything but independent, even of the designers intended them to be that way. Especially when a layer 2 protocol like spanning tree is thrashing, or a local security box is performing a local non-transparent failover, things can get very unpredictable with all sorts of timers working at various levels in the stack. IMVHO A reliable and predictable NUD is a blessing compared to ARP ;) Which is why I think that breaking synchronization/ symmetry of nodes declaring partners unreachable may have unforeseen side effects, and hence the questions. best regards, RayH Philip Homburg wrote: > In your letter dated Mon, 23 May 2011 22:03:50 +0200 you wrote: > >> e.g. 2. Say Node A (end host) declares node B (router) unreachable >> locally, but node B (router) is still up and running but has not yet >> timed out Node A. >> > > I don't think I understand your model of how a router works. > > To a large extent both directions are independent. A host has to get a packet > to any default router, and uses ND to figure out where they are and whether > they are reachable. > > A router uses ND to find where a host is. If ND fails, then the router simply > cannot deliver the packet. > > Both failures are independent. > > > --------------080300060107060109000906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Who says that NUD can't also be used to declare an interface down/ detect router neighbor loss?

Maybe think of a BGP process running over TCP receiving ICMP unreachables because the local NUD has declared the neighbor unreachable. Meanwhile the other BGP partner router is still retrying at TCP layer because NUD has not timed out on that node. Or am I seeing non-existent links here?

As someone who has had more than one evening / weekend ruined in a data centre with sniffers looking at interactions between ARP and STP thrashing about and Cisco HSRP and HP MC ServiceGuard and Network intrusion detection/ firewall failover, I would contend that these mechanisms are anything but independent, even of the designers intended them to be that way.

Especially when a layer 2 protocol like spanning tree is thrashing, or a local security box is performing a local non-transparent failover, things can get very unpredictable with all sorts of timers working at various levels in the stack.

IMVHO A reliable and predictable NUD is a blessing compared to ARP ;) Which is why I think that breaking synchronization/ symmetry of nodes declaring partners unreachable may have unforeseen side effects, and hence the questions.

best regards,
RayH


Philip Homburg wrote: 
In your letter dated Mon, 23 May 2011 22:03:50 +0200 you wrote:
  
e.g. 2. Say Node A (end host) declares node B (router) unreachable 
locally, but node B (router) is still up and running but has not yet 
timed out Node A.
    

I don't think I understand your model of how a router works.

To a large extent both directions are independent. A host has to get a packet
to any default router, and uses ND to figure out where they are and whether
they are reachable.

A router uses ND to find where a host is. If ND fails, then the router simply
cannot deliver the packet.

Both failures are independent.

--------------080300060107060109000906-- From narten@us.ibm.com Mon May 23 14:11: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 99960E0851 for ; Mon, 23 May 2011 14:11:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDZn8hpqWyvM for ; Mon, 23 May 2011 14:11:34 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by ietfa.amsl.com (Postfix) with ESMTP id 233DEE0841 for ; Mon, 23 May 2011 14:11:34 -0700 (PDT) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4NKpYD8007789 for ; Mon, 23 May 2011 16:51:34 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4NLBX4e092838 for ; Mon, 23 May 2011 17:11:33 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4NLBVrU010756 for ; Mon, 23 May 2011 18:11:32 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-221-88.mts.ibm.com [9.65.221.88]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4NLBUHc010513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2011 18:11:30 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4NLBScJ013180; Mon, 23 May 2011 17:11:29 -0400 Message-Id: <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> To: Christopher Morrow Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD In-reply-to: References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> Comments: In-reply-to Christopher Morrow message dated "Mon, 23 May 2011 16:58:00 -0400." Date: Mon, 23 May 2011 17:11:28 -0400 From: Thomas Narten Cc: "ipv6@ietf.org" , Ralph Droms 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, 23 May 2011 21:11:35 -0000 Christopher Morrow writes: > one gotcha with 'dhcp only' is perhaps folks mean: "slaac to signal v6 > is on-net, but require full config from a dhcpv6 server". > How does a host know that v6 is available otherwise? (this may be why > someone said "you don't really want to do that..') Well, if I could go back in time, I would never have defined the M&O bits at all. Just say that at startup time, invoke SLAAC & DHCPv6 both. Then use whatever is available. That would have been simple and predictable. (And avoided 10GB of mailing list discussion!) (Hmm, maybe I should just write such a spec now, given the M&O bit definitions are in the twilight zone anyway... Discussion of what to do with them was effectively removed from the last revisions of the SLAAC documents, so now there is no clear guidance on how to process them. The IETF at its finest...) Thomas From v6ops@globis.net Mon May 23 14:40: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 2DFA5E0867 for ; Mon, 23 May 2011 14:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.656 X-Spam-Level: X-Spam-Status: No, score=-3.656 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] 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 hd37-xZ7ytVr for ; Mon, 23 May 2011 14:40:25 -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 D93D1E079C for ; Mon, 23 May 2011 14:40:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id CBD37870083; Mon, 23 May 2011 23:40:23 +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 DxeMpbFubEi0; Mon, 23 May 2011 23:40:18 +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 B9119870023; Mon, 23 May 2011 23:40:18 +0200 (CEST) Message-ID: <4DDAD442.7040400@globis.net> Date: Mon, 23 May 2011 23:40:18 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Philip Homburg Subject: Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt References: <4DDACD31.9020602@globis.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070502020308030209080809" 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, 23 May 2011 21:40:26 -0000 This is a multi-part message in MIME format. --------------070502020308030209080809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Philip Homburg wrote: > In your letter dated Mon, 23 May 2011 23:10:09 +0200 you wrote: > >> Who says that NUD can't also be used to declare an interface down/ >> detect router neighbor loss? >> >> Maybe think of a BGP process running over TCP receiving ICMP >> unreachables because the local NUD has declared the neighbor >> unreachable. Meanwhile the other BGP partner router is still retrying at >> TCP layer because NUD has not timed out on that node. Or am I seeing >> non-existent links here? >> > > Let's say router A declares router B unreachable because of some ND problem. > Meanwhile router B still considers router A reachable. > > Now obviously, router A (and the routing system) will try to avoid routing > packets from A to B because that link is down. > > B still assumes that A is reachable so it will continue to forward packets to > A. As long a A does not drop those packets, everything will be fine. I don't > think there is a reason to drop incoming packets when a neighbor on a link is > unreachable, but if an implementation does that, then that will break the > independence and will cause problems. > > But for relatively stable links consisting of just BGP peers, it may make more > sense to just hardwire the ND entries and disable ND. > > > You are probably 100% correct for BGP. And I'm reasonably convinced BGP is relatively bullet-proof (even if one well-known network provider that I know does not give BGP TCP sessions priority over normal user traffic, so BGP neighbors can flap on high user load.) It was just one example off the top of my head of a dependency. The only point I'm making is that there may well be stuff out there that has become reliant on the current symmetrical behavior of NUD. ARP caches generally took a very long time before they started sending back an ICMP unreachable. AFAIK NUD is pretty instantaneous once it declares something unreachable. It was after all a selling-point of NDP and neighbor discovery in general that it "fixed" the half-open link problem. RFC 2461 "Unlike ARP, Neighbor Discovery detects half-link failures" And now it mightn't live up to that promise: at least in transitory situations that might last for an extended period of comparable duration to timeouts in other protocol layers / applications, unless the timers/ retry counts are synchronized across all nodes on the link. Timers and race conditions can be very tricky to catch/ debug, as I'm sure you know. Just raising a flag. Maybe this is significant, maybe not. Just thought I'd ask. regards, RayH --------------070502020308030209080809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Philip Homburg wrote: 
In your letter dated Mon, 23 May 2011 23:10:09 +0200 you wrote:
  
Who says that NUD can't also be used to declare an interface down/ 
detect router neighbor loss?

Maybe think of a BGP process running over TCP receiving ICMP 
unreachables because the local NUD has declared the neighbor 
unreachable. Meanwhile the other BGP partner router is still retrying at 
TCP layer because NUD has not timed out on that node. Or am I seeing 
non-existent links here?
    

Let's say router A declares router B unreachable because of some ND problem.
Meanwhile router B still considers router A reachable.

Now obviously, router A (and the routing system) will try to avoid routing
packets from A to B because that link is down.

B still assumes that A is reachable so it will continue to forward packets to
A. As long a A does not drop those packets, everything will be fine. I don't
think there is a reason to drop incoming packets when a neighbor on a link is
unreachable, but if an implementation does that, then that will break the
independence and will cause problems.

But for relatively stable links consisting of just BGP peers, it may make more
sense to just hardwire the ND entries and disable ND.
You are probably 100% correct for BGP. And I'm reasonably convinced BGP is relatively bullet-proof (even if one well-known network provider that I know does not give BGP TCP sessions priority over normal user traffic, so BGP neighbors can flap on high user load.) It was just one example off the top of my head of a dependency.

The only point I'm making is that there may well be stuff out there that has become reliant on the current symmetrical behavior of NUD. ARP caches generally took a very long time before they started sending back an ICMP unreachable. AFAIK NUD is pretty instantaneous once it declares something unreachable.

It was after all a selling-point of NDP and neighbor discovery in general that it "fixed" the half-open link problem.

RFC 2461 "Unlike ARP, Neighbor Discovery detects half-link failures"

And now it mightn't live up to that promise: at least in transitory situations that might last for an extended period of comparable duration to timeouts in other protocol layers / applications, unless the timers/ retry counts are synchronized across all nodes on the link. Timers and race conditions can be very tricky to catch/ debug, as I'm sure you know.

Just raising a flag. Maybe this is significant, maybe not. Just thought I'd ask.

regards,
RayH
--------------070502020308030209080809-- From brian.e.carpenter@gmail.com Mon May 23 14:52:04 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 4DA5EE07B8 for ; Mon, 23 May 2011 14:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 LigdVR3r2fkU for ; Mon, 23 May 2011 14:52:03 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id BAB7DE069C for ; Mon, 23 May 2011 14:52:03 -0700 (PDT) Received: by pxi2 with SMTP id 2so3636419pxi.38 for ; Mon, 23 May 2011 14:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=m9SeFFEmrGDVvKsDi3EPvk0ugrWkEm00ByQqK92AuUI=; b=XnK3FlUdsryq88UNU2H8/3YlVG66Sfo9q9wPwLaKzwDiLuvpDlBCuwa7HMQpeDjbdD JFElmDL5OVjSVCwIrs32CfGkVUIUt9MWbVs3mtfWTv5FfrGD9PI/gGx59XURIFZHS7DX 4LqaYvY27EemYexcDcCLX7gpMw+Ow7iQ1xa20= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=ZGaIwHsyGbVG8UnCZZOMMJAR2dKYrArqLuR+0C48qRuSDmkyaQOVzChMvvca0QWJRc JdlPO/G4nYIQCWGBn6tBcRQ9JTAwVHgk0WRDXTjtHCxyysOBS8nWjxJgm+4vLPHzr5Tm WEZGzZqezNMFkmRKL2vh6OxKQWukchGcutfnY= Received: by 10.142.149.15 with SMTP id w15mr887918wfd.325.1306187523315; Mon, 23 May 2011 14:52:03 -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 k7sm6161796wfa.2.2011.05.23.14.52.00 (version=SSLv3 cipher=OTHER); Mon, 23 May 2011 14:52:02 -0700 (PDT) Message-ID: <4DDAD6FE.2030807@gmail.com> Date: Tue, 24 May 2011 09:51:58 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> In-Reply-To: <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Ralph Droms 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, 23 May 2011 21:52:04 -0000 Thomas, On 2011-05-24 09:11, Thomas Narten wrote: > Christopher Morrow writes: > >> one gotcha with 'dhcp only' is perhaps folks mean: "slaac to signal v6 >> is on-net, but require full config from a dhcpv6 server". >> How does a host know that v6 is available otherwise? (this may be why >> someone said "you don't really want to do that..') > > Well, if I could go back in time, I would never have defined the M&O > bits at all. > > Just say that at startup time, invoke SLAAC & DHCPv6 both. Then use > whatever is available. That would have been simple and > predictable. (And avoided 10GB of mailing list discussion!) > > (Hmm, maybe I should just write such a spec now, Please do. It is one of the gaps identified in RFC 5887, btw. Brian given the M&O bit > definitions are in the twilight zone anyway... Discussion of what to > do with them was effectively removed from the last revisions of the > SLAAC documents, so now there is no clear guidance on how to process > them. The IETF at its finest...) > > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From ipng@69706e6720323030352d30312d31340a.nosense.org Mon May 23 14:56: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 43F88E06E7 for ; Mon, 23 May 2011 14:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 SXh5zHBElvbZ for ; Mon, 23 May 2011 14:56:40 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 5076FE069C for ; Mon, 23 May 2011 14:56:40 -0700 (PDT) Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QOd73-00028L-80; Tue, 24 May 2011 07:26:33 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 776E63B338; Tue, 24 May 2011 07:26:32 +0930 (CST) Date: Tue, 24 May 2011 07:26:31 +0930 From: Mark Smith To: Thomas Narten Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Message-ID: <20110524072631.737ee12c@opy.nosense.org> In-Reply-To: <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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" , Ralph Droms 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, 23 May 2011 21:56:41 -0000 Hi Thomas, On Mon, 23 May 2011 17:11:28 -0400 Thomas Narten wrote: > Christopher Morrow writes: > > > one gotcha with 'dhcp only' is perhaps folks mean: "slaac to signal v6 > > is on-net, but require full config from a dhcpv6 server". > > How does a host know that v6 is available otherwise? (this may be why > > someone said "you don't really want to do that..') > > Well, if I could go back in time, I would never have defined the M&O > bits at all. > > Just say that at startup time, invoke SLAAC & DHCPv6 both. Then use > whatever is available. That would have been simple and > predictable. (And avoided 10GB of mailing list discussion!) > What if both are available, accidentally or intentionally (due to misunderstanding that it should be one or the other)? Conflict resolution in these sorts of situations isn't always simple and predictable. You've now got twice as many things to configure correctly, and at least twice as many things to troubleshoot if they don't work. I'd think either leaving the status quo, or dumping one of them, and adding the features to the remaining one to make it the functionally equivalent to the dumped one would be a better thing to do at this time. I'm not particularly pro-SLAAC, however I sit back and wonder what is missing from it that makes DHCP essential? It seems to me that the functional reason people want DHCP is that they think it will track address use - but it won't if end-nodes are manually assigned static addresses. SLAAC won't prevent that either - so both SLAAC and DHCP aren't adequate if your goal is to track address use. In other words, its a problem that neither of them adequately address and have tried to address. > (Hmm, maybe I should just write such a spec now, given the M&O bit > definitions are in the twilight zone anyway... Discussion of what to > do with them was effectively removed from the last revisions of the > SLAAC documents, so now there is no clear guidance on how to process > them. The IETF at its finest...) > I'm a bit confused, I find this text in RFC4862 quite clear as to what to do - M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information. O 1-bit "Other configuration" flag. When set, it indicates that other configuration information is available via DHCPv6. Examples of such information are DNS-related information or information on other servers within the network. About the only thing I'd have changed in the above to make it more clearer is to use the word "stateful" in the M section when referring to DHCPv6 and "stateless" in the O section. Regards, Mark. From brian.e.carpenter@gmail.com Mon May 23 15:13:25 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 45B29E0682 for ; Mon, 23 May 2011 15:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 YzWNmaLt3qXa for ; Mon, 23 May 2011 15:13:24 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0C0E079C for ; Mon, 23 May 2011 15:13:24 -0700 (PDT) Received: by pxi2 with SMTP id 2so3644406pxi.38 for ; Mon, 23 May 2011 15:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o83G5G/gyobmUIF7+REHCxk7NHnLvyKElxOiirDq3/8=; b=TS4/rNBY5Hp1BVhp6JUdSFNZb4fSYVdNeWb79DM9x2/G0hZdcQ6i9WEdUdXFdattIs Rog9Mt0bcY8vsnQh6Ho3hAvOlinqfS5SmiDOyfziQEh42+aYSyo++/Focb3kZNhxxXeA gE2CvXMBHtlZIQHwlI1rhYDBHUZVHb/RWUlzk= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=C/PFcDNvsfpfsMDF4IUMLu4wPPxDoIVdnjjKrwpUq0XsMwbB0Fxj44WgTq3f914dOa RCW1TazgUseeRkeRFCUr1opLy/jGdi9zZWF5QwPfOUOFH/0Qq0v08DJsbeO7f2GSlmOP hnPQlX1SPUVmKdnNj1sIxwd2dhzkZA68o7Qu8= Received: by 10.68.39.74 with SMTP id n10mr2383992pbk.242.1306188804351; Mon, 23 May 2011 15:13:24 -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 i7sm4585832pbs.20.2011.05.23.15.13.19 (version=SSLv3 cipher=OTHER); Mon, 23 May 2011 15:13:23 -0700 (PDT) Message-ID: <4DDADBFD.7000803@gmail.com> Date: Tue, 24 May 2011 10:13:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Smith Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> In-Reply-To: <20110524072631.737ee12c@opy.nosense.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "ipv6@ietf.org" , Ralph Droms 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, 23 May 2011 22:13:25 -0000 Mark, On 2011-05-24 09:56, Mark Smith wrote: ... > I'm not particularly pro-SLAAC, however I sit back and wonder what is > missing from it that makes DHCP essential? To be blunt, that conversation isn't worth having. SLAAC is clearly essential for isolated or bootstrapping networks to self-configure. DHCP is clearly viewed as essential by many network managers. EOM. ... >> (Hmm, maybe I should just write such a spec now, given the M&O bit >> definitions are in the twilight zone anyway... Discussion of what to >> do with them was effectively removed from the last revisions of the >> SLAAC documents, so now there is no clear guidance on how to process >> them. The IETF at its finest...) >> > > I'm a bit confused, I find this text in RFC4862 quite clear as to what > to do - It doesn't specify startup defaults and the like. RFC 5887, Section 5.1.1, bottom of page 12, discusses this. If you're concerned about SLAAC/DHCPv6 conflict resolution, see draft-liu-ipv6-renum-conflicts (and join the renum@ietf.org list). Brian From ipng@69706e6720323030352d30312d31340a.nosense.org Mon May 23 15:31:59 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 938B0E0866 for ; Mon, 23 May 2011 15:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 yClUSAezo2cL for ; Mon, 23 May 2011 15:31:58 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 53573E0837 for ; Mon, 23 May 2011 15:31:58 -0700 (PDT) Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QOdfI-0003UQ-7T; Tue, 24 May 2011 08:01:56 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 9996B3B338; Tue, 24 May 2011 08:01:55 +0930 (CST) Date: Tue, 24 May 2011 08:01:54 +0930 From: Mark Smith To: Brian E Carpenter Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Message-ID: <20110524080154.513002bf@opy.nosense.org> In-Reply-To: <4DDADBFD.7000803@gmail.com> References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <4DDADBFD.7000803@gmail.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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: Thomas Narten , "ipv6@ietf.org" , Ralph Droms 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, 23 May 2011 22:31:59 -0000 On Tue, 24 May 2011 10:13:17 +1200 Brian E Carpenter wrote: > Mark, > > On 2011-05-24 09:56, Mark Smith wrote: > ... > > I'm not particularly pro-SLAAC, however I sit back and wonder what is > > missing from it that makes DHCP essential? > > To be blunt, that conversation isn't worth having. SLAAC is clearly > essential for isolated or bootstrapping networks to self-configure. > DHCP is clearly viewed as essential by many network managers. EOM. > " 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements." It's shame IPv6 fails on that count. I'm genuinely asking what the improvements are to justify why two mechanisms that are almost functionally equivalent. > ... > > >> (Hmm, maybe I should just write such a spec now, given the M&O bit > >> definitions are in the twilight zone anyway... Discussion of what to > >> do with them was effectively removed from the last revisions of the > >> SLAAC documents, so now there is no clear guidance on how to process > >> them. The IETF at its finest...) > >> > > > > I'm a bit confused, I find this text in RFC4862 quite clear as to what > > to do - > > It doesn't specify startup defaults and the like. RFC 5887, Section 5.1.1, > bottom of page 12, discusses this. > > If you're concerned about SLAAC/DHCPv6 conflict resolution, see > draft-liu-ipv6-renum-conflicts (and join the renum@ietf.org list). > Thanks for the reference, I'll have a look. Regards, Mark. From albert.e.manfredi@boeing.com Mon May 23 16:07: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 E4A31E0696 for ; Mon, 23 May 2011 16:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 tiLx4gt0f280 for ; Mon, 23 May 2011 16:07:34 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 05F6DE067B for ; Mon, 23 May 2011 16:07:33 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4NN7Jva029927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 May 2011 18:07:19 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p4NN7JR5009457; Mon, 23 May 2011 18:07:19 -0500 (CDT) Received: from XCH-MWHT-03.mw.nos.boeing.com (xch-mwht-03.mw.nos.boeing.com [134.57.119.161]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4NN7IgF009447 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 23 May 2011 18:07:18 -0500 (CDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-03.mw.nos.boeing.com ([134.57.119.161]) with mapi; Mon, 23 May 2011 18:07:18 -0500 From: "Manfredi, Albert E" To: Mark Smith Date: Mon, 23 May 2011 18:07:15 -0500 Subject: RE: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AcwZmUja0e+fcC9dQVGCE9K6tcmQ2QABEhPQ Message-ID: References: <201105232010 .p4NKAV9X012654@cichlid.raleigh.ibm.com><53E999C4-E50D-49C9-9B02-8AD7B56419 05@gmail.com><201105232 111.p4NLBScJ013180@cichlid.raleigh.ibm.com><20110524072631.737ee12c@opy.nosense.org><4DDADBFD.7000803@gmail.com> <20110524080154.513002bf@opy.nosense.org> In-Reply-To: <20110524080154.513002bf@opy.nosense.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 23 May 2011 23:07:35 -0000 Mark Smith wrote: > " 3.2 If there are several ways of doing the same thing, choose one. > If a previous design, in the Internet context or elsewhere, has > successfully solved the same problem, choose the same solution > unless > there is a good technical reason not to. Duplication of the same > protocol functionality should be avoided as far as possible, without > of course using this argument to reject improvements." >=20 >=20 > It's shame IPv6 fails on that count. I'm genuinely asking what the > improvements are to justify why two mechanisms that are almost > functionally equivalent. Mark, as I suggested previously, DHCP is useful in cases where you need the= IP addresses of hosts in a network to be predictable. I have no idea why c= able systems want DHCP, but I'm saying that IN GENERAL, if hosts needs to k= now a priori what the address of other hosts is, SLAAC falls flat on its fa= ce. For example, a peer-to-peer network, where you don't want to rely on a DNS. Bert From christopher.morrow@gmail.com Mon May 23 16:50: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 DFCC0E0844 for ; Mon, 23 May 2011 16:50: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdUurHcQRddS for ; Mon, 23 May 2011 16:50:09 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 192B7E0879 for ; Mon, 23 May 2011 16:44:27 -0700 (PDT) Received: by wyb29 with SMTP id 29so5271440wyb.31 for ; Mon, 23 May 2011 16:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=thDspRj3I6ovIFFz6YpdpeYvetjNYohniovKl+s/6s0=; b=f/ZDfBCsmUjKwM6w6/Trck2YM5ZISamgpXEh2GYwrNE/w6ThirXyTk4Wn61FczyqLe 4gDqmBSGSl4aBzD9+GRuimkVXWvE4NoMG7IwdqWBxgx6nKRyB9atPphJc/vRWNQ1WnXN XdpCry9xfKXrlPfmlfIsLJ3/mAjXQUpnhgg+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g0z2TSkM/r3CNNjea+VMZn/+GKjqqTCeGXSAS53oB1jhbryF9oO+usYAHUoai7zLzZ ilu0PvfC9UkFENHKq1XieyRI4ocU7NhimlV7FSVOjkZZonmZWpFk781rKmRt+tEUTfvU t2OL2fy9hkBxxKAx4XSXgw/jKxYs8b77AJC3U= MIME-Version: 1.0 Received: by 10.216.239.73 with SMTP id b51mr2710808wer.60.1306194267102; Mon, 23 May 2011 16:44:27 -0700 (PDT) Received: by 10.216.73.212 with HTTP; Mon, 23 May 2011 16:44:27 -0700 (PDT) In-Reply-To: <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> Date: Mon, 23 May 2011 19:44:27 -0400 Message-ID: Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: Christopher Morrow To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipv6@ietf.org" , Ralph Droms 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, 23 May 2011 23:50:10 -0000 On Mon, May 23, 2011 at 5:11 PM, Thomas Narten wrote: > Christopher Morrow writes: > >> one gotcha with 'dhcp only' is perhaps folks mean: "slaac to signal v6 >> is on-net, but require full config from a dhcpv6 server". >> How does a host know that v6 is available otherwise? (this may be why >> someone said "you don't really want to do that..') > > Well, if I could go back in time, I would never have defined the M&O > bits at all. > > Just say that at startup time, invoke SLAAC & DHCPv6 both. Then use > whatever is available. That would have been simple and > predictable. (And avoided 10GB of mailing list discussion!) > > (Hmm, maybe I should just write such a spec now, given the M&O bit > definitions are in the twilight zone anyway... Discussion of what to > do with them was effectively removed from the last revisions of the > SLAAC documents, so now there is no clear guidance on how to process > them. The IETF at its finest...) ok, so ... as a thought experiment, in v4 you wake up, decide you have no address and are supposed to dhcp for that.. in v6, you wake up decide you have no address (and don't know if v4/v6 are available)... if you are configured for v6 dhcp, you make that request and get all the 'right' data. Essentially, spec dhcpv6 host actions to be the same as v4? > Thomas > From christopher.morrow@gmail.com Mon May 23 16:51: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 27E52E07C9 for ; Mon, 23 May 2011 16:51:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fq-EFeq-xoY for ; Mon, 23 May 2011 16:51:49 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 684B6E086B for ; Mon, 23 May 2011 16:48:44 -0700 (PDT) Received: by wwa36 with SMTP id 36so4656977wwa.13 for ; Mon, 23 May 2011 16:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=blYN3h72RPHJPzRsuKQTLxClx69Mz094fGW8ERR6deU=; b=Hu4Ya7quZnaXws4El8xlgLvp6wOxz7chmEDzBKLVXvxFoMjo/mSpV1DB5EvaSlEoxV 7/+KR9yiJLU20VxilJFRwvsfUIZBgPHEo/MsYmf/XXXnufHdvq9+MmNePzRSQ95QTLw9 MU+dyNnU/njSPs1q6Vn36kd4RdaoaIjmNxogw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Y9yG9vX10IHF/We1U2Yw0ekxQkQf7kRNBzIo4wEMN94eYDbpmZE8wlPtseSzVRm0/N lYd6DriEN5IhmBXjaqg8/g/jeL4t7MfS/8UxBENZaXP4pd+VJu7npsPyuFSc91mAg2Cf dqlmgBS1QYyN/t8RF4CAkWmKeyPIA5/qiym6k= MIME-Version: 1.0 Received: by 10.216.254.82 with SMTP id g60mr2591674wes.90.1306194523415; Mon, 23 May 2011 16:48:43 -0700 (PDT) Received: by 10.216.73.212 with HTTP; Mon, 23 May 2011 16:48:43 -0700 (PDT) In-Reply-To: References: <20110524072631.737ee12c@opy.nosense.org> <4DDADBFD.7000803@gmail.com> <20110524080154.513002bf@opy.nosense.org> Date: Mon, 23 May 2011 19:48:43 -0400 Message-ID: Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: Christopher Morrow To: "Manfredi, Albert E" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 23 May 2011 23:51:50 -0000 On Mon, May 23, 2011 at 7:07 PM, Manfredi, Albert E wrote: > Mark Smith wrote: > Mark, as I suggested previously, DHCP is useful in cases where you need t= he IP addresses of hosts in a network to be predictable. I have no idea why= cable systems want DHCP, but I'm saying that IN GENERAL, if hosts needs to= know a priori what the address of other hosts is, SLAAC falls flat on its = face. > > For example, a peer-to-peer network, where you don't want to rely on a DN= S. really, the simplest case is enterprise networks: joe's machine always gets address 1:2:3::4/128 janes machine always gets 1.2.3::5/128 this way techsupport always has a predictable mapping for these hosts, they can identify form log messages over time what jane vs joe did... not have ot worry about keeping track of the vagaries of privacy addressing and jane/joe/etc flip flopping around the subnet at "random". Brian's point though is fair: Drive through, nothing new to discuss here (wrt WHY) -chris From narten@us.ibm.com Mon May 23 16:51: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 0C66DE07EA for ; Mon, 23 May 2011 16:51:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48UZyOv8IlLf for ; Mon, 23 May 2011 16:51:50 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by ietfa.amsl.com (Postfix) with ESMTP id 63709E0804 for ; Mon, 23 May 2011 16:49:01 -0700 (PDT) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4NNLjCa018782 for ; Mon, 23 May 2011 19:21:45 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4NNmsAv1302716 for ; Mon, 23 May 2011 19:48:54 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4NNmspe015155 for ; Mon, 23 May 2011 20:48:54 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-221-88.mts.ibm.com [9.65.221.88]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4NNmrco015140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2011 20:48:54 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4NNmqHJ015491; Mon, 23 May 2011 19:48:53 -0400 Message-Id: <201105232348.p4NNmqHJ015491@cichlid.raleigh.ibm.com> To: Christopher Morrow Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD In-reply-to: References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> Comments: In-reply-to Christopher Morrow message dated "Mon, 23 May 2011 19:44:27 -0400." Date: Mon, 23 May 2011 19:48:52 -0400 From: Thomas Narten Cc: "ipv6@ietf.org" , Ralph Droms 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, 23 May 2011 23:51:51 -0000 > ok, so ... as a thought experiment, in v4 you wake up, decide you have > no address and are supposed to dhcp for that.. > in v6, you wake up decide you have no address (and don't know if v4/v6 > are available)... if you are configured for v6 dhcp, you make that > request and get all the 'right' data. > Essentially, spec dhcpv6 host actions to be the same as v4? yes. Have DHCPv6 and SLAAC run independently. If you get stuff via one or the other or both, just use them. The mistake of the M&O bits was that you needed an RA to tell you to use DHCP. But if the bits weren't set right, or something, you wouldn't run DHCP in cases where you should have. Just decouple the two protocols completely. The one downside is that you run DHCP even if there are no DHCP servers. In some environments, that is extra traffic the operator might not want. I recall many long threads about how the cost of those extra DHCP pacekts on a wireless network were unacceptable... Thomas From christopher.morrow@gmail.com Mon May 23 17:00: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 938A2E069A for ; Mon, 23 May 2011 17:00:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+Fo1YT17Cm6 for ; Mon, 23 May 2011 17:00:19 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id C561AE0651 for ; Mon, 23 May 2011 17:00:18 -0700 (PDT) Received: by wwk4 with SMTP id 4so1951905wwk.1 for ; Mon, 23 May 2011 17:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qJdUDSL46PdcuLHcBoSvsNvB3mDyLVc6IPrlgUSA/js=; b=k2MEhtvthR06DMUO9mmNeln0VOQUTIKlhoUqJCGO9qiV8CB2MtGQFsHgJ9xWxXfIp8 92QUZ3oG/KGmSuzCgFwkhDYY9OHMcpKdjGTlVMxqspHHXePcSvtRmTvAeAPXv/5qz3Gd lTrLA6acDrM6Z2ZxTDlzY07MSfVIeMFdH4u9c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZaDfk48Cbc3Cs5qsdk/82UN+8wguiuTk4yrf6fZkqCYGpof2NwPFfv/027jkZVVlgc aJyRxSwZSc1tMgMSgoNRzNt/isdCGkS1owOhpHfIMzm54eDPSkHsKcEJ6hO3o7tUky5j cxq4xjSK0H+ODxTEMeGhP2ZVPTXswCfjT/a1Y= MIME-Version: 1.0 Received: by 10.216.220.194 with SMTP id o44mr2737618wep.105.1306195217570; Mon, 23 May 2011 17:00:17 -0700 (PDT) Received: by 10.216.73.212 with HTTP; Mon, 23 May 2011 17:00:17 -0700 (PDT) In-Reply-To: <201105232348.p4NNmqHJ015491@cichlid.raleigh.ibm.com> References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <201105232348.p4NNmqHJ015491@cichlid.raleigh.ibm.com> Date: Mon, 23 May 2011 20:00:17 -0400 Message-ID: Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: Christopher Morrow To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipv6@ietf.org" , Ralph Droms 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, 24 May 2011 00:00:19 -0000 On Mon, May 23, 2011 at 7:48 PM, Thomas Narten wrote: > >> ok, so ... as a thought experiment, in v4 you wake up, decide you have >> no address and are supposed to dhcp for that.. >> in v6, you wake up decide you have no address (and don't know if v4/v6 >> are available)... if you are configured for v6 dhcp, you make that >> request and get all the 'right' data. > >> Essentially, spec dhcpv6 host actions to be the same as v4? > > yes. > > Have DHCPv6 and SLAAC run independently. If you get stuff via one or > the other or both, just use them. > > The mistake of the M&O bits was that you needed an RA to tell you to > use DHCP. But if the bits weren't set right, or something, you > wouldn't run DHCP in cases where you should have. Just decouple the > two protocols completely. > > The one downside is that you run DHCP even if there are no DHCP > servers. In some environments, that is extra traffic the operator > might not want. I recall many long threads about how the cost of those > extra DHCP pacekts on a wireless network were unacceptable... I guess I was thinking that today you have a device, it either is configured to do dhcp or is manually configured or just is broken. In the v6 world you could just forget M&O and require someone to configure (via os config tweaks that already exist for v4 anyway) dhcpv6 if anything more complex than 'subnet + random address + defgw' are required (or if they just like DHCP over SLAAC). (are we saying the same thing? I'm --coffee so...) -chris From narten@us.ibm.com Mon May 23 17:10: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 A8EF6E07F2 for ; Mon, 23 May 2011 17:10:35 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 0lVIaVFlsZ+r for ; Mon, 23 May 2011 17:10:17 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBAFE06DB for ; Mon, 23 May 2011 17:10:17 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4O031mA001462 for ; Mon, 23 May 2011 18:03:01 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4O0AB6d135034 for ; Mon, 23 May 2011 18:10:11 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4O0AAYx028596 for ; Mon, 23 May 2011 18:10:10 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-221-88.mts.ibm.com [9.65.221.88]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4O0A9KS028586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 May 2011 18:10:10 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4O0A4SA015678; Mon, 23 May 2011 20:10:09 -0400 Message-Id: <201105240010.p4O0A4SA015678@cichlid.raleigh.ibm.com> To: Christopher Morrow Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD In-reply-to: References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <201105232348.p4NNmqHJ015491@cichlid.raleigh.ibm.com> Comments: In-reply-to Christopher Morrow message dated "Mon, 23 May 2011 20:00:17 -0400." Date: Mon, 23 May 2011 20:10:04 -0400 From: Thomas Narten Cc: "ipv6@ietf.org" , Ralph Droms 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, 24 May 2011 00:10:35 -0000 > I guess I was thinking that today you have a device, it either is > configured to do dhcp or is manually configured or just is broken. In > the v6 world you could just forget M&O and require someone to > configure (via os config tweaks that already exist for v4 anyway) > dhcpv6 if anything more complex than 'subnet + random address + defgw' > are required (or if they just like DHCP over SLAAC). Something like that. The key is that both are implemented. You can then have defaults for whether or not they are enabled out of the box, with switches to override the defaults. But I'm thinking of zeroconfig in the general case. Just plug it into the net, and it all just works. That means DHCP and SLAAC on by default. But zeroconfig isn't all that useful for some types of devices. For servers, routers, and other more "infrastructury" devices, it may be fine to require some config before you plug the machine in. Of course, manual config is always an option, in which case you turn off SLAAC & DHCP (except for LL addrs). Thomas From cabo@tzi.org Tue May 24 01:05: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 A5264E073C for ; Tue, 24 May 2011 01:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 JLlM5X0sy0XD for ; Tue, 24 May 2011 01:05:27 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B4831E073B for ; Tue, 24 May 2011 01:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p4O85LEt000613; Tue, 24 May 2011 10:05:21 +0200 (CEST) Received: from [192.168.217.101] (p5489BE21.dip.t-dialin.net [84.137.190.33]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C9EFAC24; Tue, 24 May 2011 10:05:20 +0200 (CEST) Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <201105232348.p4NNmqHJ015491@cichlid.raleigh.ibm.com> Date: Tue, 24 May 2011 10:05:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0371250C-B63A-4CC3-A880-5874B728141E@tzi.org> References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <201105232348.p4NNmqHJ015491@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: IPv6 WG 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, 24 May 2011 08:05:27 -0000 On May 24, 2011, at 01:48, Thomas Narten wrote: > The one downside is that you run DHCP even if there are no DHCP > servers. In some environments, that is extra traffic ... and an extra attack (if you happen to have RA-guard but no = protection for DHCP). Maybe not that much of a difference, but still a thing to take note of. The extra traffic is a little more interesting in constrained = node/networks (e.g., 6LoWPAN). I think we will continue to use the M bit for gating DHCP. (See section 3.2 of draft-ietf-6lowpan-nd-15.txt for details of how we = do this.) Maybe our needs are not relevant for the ND-classic spec, but this is = just one more data point. Gruesse, Carsten From pch-b2B3A6689@u-1.phicoh.com Mon May 23 12:09: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 57FE1E07D0 for ; Mon, 23 May 2011 12:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 0EQVZuwqIPRd for ; Mon, 23 May 2011 12:09:57 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 544DCE06F9 for ; Mon, 23 May 2011 12:09:55 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QOaVe-0001pxC; Mon, 23 May 2011 21:09:46 +0200 Message-Id: To: Erik Nordmark Subject: Re: Neighbor Unreachability Detection is too impatient From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Mon, 23 May 2011 11:46:29 -0700 ." <4DDAAB85.8000103@acm.org> Date: Mon, 23 May 2011 21:09:44 +0200 X-Mailman-Approved-At: Tue, 24 May 2011 01:16:06 -0700 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, 23 May 2011 19:09:58 -0000 In your letter dated Mon, 23 May 2011 11:46:29 -0700 you wrote: >This draft proposes to change the requirement that NUD can not >retransmit more than three times, so that NUD can be more robust against >temporary network outages. > >Comments? Do you have more data on how this problem actually shows up practice? The draft suggests that the main difference is more multicast traffic. How many hosts do you need to have on a single link for this to significantly impact the performance of the link? From pch-b2B3A6689@u-1.phicoh.com Mon May 23 13:33:52 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 DB1E2E069C for ; Mon, 23 May 2011 13:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 O5mgVcsTna-v for ; Mon, 23 May 2011 13:33:52 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id DBC91E0819 for ; Mon, 23 May 2011 13:33:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QObow-0001hFC; Mon, 23 May 2011 22:33:46 +0200 Message-Id: To: Ray Hunter Subject: Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com In-reply-to: Your message of "Mon, 23 May 2011 22:03:50 +0200 ." <4DDABDA6.2070705@globis.net> Date: Mon, 23 May 2011 22:33:46 +0200 X-Mailman-Approved-At: Tue, 24 May 2011 01:16:12 -0700 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, 23 May 2011 20:33:53 -0000 In your letter dated Mon, 23 May 2011 22:03:50 +0200 you wrote: >e.g. 2. Say Node A (end host) declares node B (router) unreachable >locally, but node B (router) is still up and running but has not yet >timed out Node A. I don't think I understand your model of how a router works. To a large extent both directions are independent. A host has to get a packet to any default router, and uses ND to figure out where they are and whether they are reachable. A router uses ND to find where a host is. If ND fails, then the router simply cannot deliver the packet. Both failures are independent. From pch-b2B3A6689@u-1.phicoh.com Mon May 23 14:23:04 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 01372E0876 for ; Mon, 23 May 2011 14:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 qiz1hujNfTld for ; Mon, 23 May 2011 14:23:03 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id B204DE082F for ; Mon, 23 May 2011 14:23:01 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QOcaZ-0001hFC; Mon, 23 May 2011 23:22:59 +0200 Message-Id: To: Ray Hunter Subject: Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <4DDACD31.9020602@globis.net> In-reply-to: Your message of "Mon, 23 May 2011 23:10:09 +0200 ." <4DDACD31.9020602@globis.net> Date: Mon, 23 May 2011 23:22:59 +0200 X-Mailman-Approved-At: Tue, 24 May 2011 01:16:12 -0700 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, 23 May 2011 21:23:04 -0000 In your letter dated Mon, 23 May 2011 23:10:09 +0200 you wrote: >Who says that NUD can't also be used to declare an interface down/ >detect router neighbor loss? > >Maybe think of a BGP process running over TCP receiving ICMP >unreachables because the local NUD has declared the neighbor >unreachable. Meanwhile the other BGP partner router is still retrying at >TCP layer because NUD has not timed out on that node. Or am I seeing >non-existent links here? Let's say router A declares router B unreachable because of some ND problem. Meanwhile router B still considers router A reachable. Now obviously, router A (and the routing system) will try to avoid routing packets from A to B because that link is down. B still assumes that A is reachable so it will continue to forward packets to A. As long a A does not drop those packets, everything will be fine. I don't think there is a reason to drop incoming packets when a neighbor on a link is unreachable, but if an implementation does that, then that will break the independence and will cause problems. But for relatively stable links consisting of just BGP peers, it may make more sense to just hardwire the ND entries and disable ND. From narten@us.ibm.com Tue May 24 05:50: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 CDA40E06A2 for ; Tue, 24 May 2011 05:50:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nv-k8FZSksva for ; Tue, 24 May 2011 05:50:02 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id 5A85BE066A for ; Tue, 24 May 2011 05:50:02 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4OCWfb8015033 for ; Tue, 24 May 2011 06:32:41 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p4OCnsAc157232 for ; Tue, 24 May 2011 06:49:55 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4O6nsR8003930 for ; Tue, 24 May 2011 00:49:54 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-251-50.mts.ibm.com [9.65.251.50]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4O6nqs1003820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 00:49:53 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4OCnpfS006392; Tue, 24 May 2011 08:49:51 -0400 Message-Id: <201105241249.p4OCnpfS006392@cichlid.raleigh.ibm.com> To: Ray Hunter Subject: Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt In-reply-to: <4DDABDA6.2070705@globis.net> References: <4DDABDA6.2070705@globis.net> Comments: In-reply-to Ray Hunter message dated "Mon, 23 May 2011 22:03:50 +0200." Date: Tue, 24 May 2011 08:49:51 -0400 From: Thomas Narten 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: Tue, 24 May 2011 12:50:02 -0000 Ray Hunter writes: > Are there any implications for different nodes having different NUD > timeout behavior on a link, and this no longer being symmetrical? I do not think so. > e.g. 1. Say Node A (router) declares node C (end node) unreachable but > Node B (alternate back up router) has not yet timed out node C? IMO, this should not be an issue. > Now the case of router failover.... > e.g. 2. Say Node A (end host) declares node B (router) unreachable > locally, but node B (router) is still up and running but has not yet > timed out Node A. At this point there is already a problem, because packets do not seem to be flowing. The sooner both peers recognize that the path is not working and find an alternative the better. But by definition, the two peers will *never* be able to determine this situation at *exactly* the same time. That is, there will always be cases where NodeA determines NodeB is unreachable before NodeB detects NodeA is unreachable (and vice versa). While it would be better to have both peers determine that the path to each other is down ASAP, there is not and has never been a requirement that both peers detect that a path is not working at the same time. Thomas From narten@us.ibm.com Tue May 24 06:02: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 EDCA7E06A8 for ; Tue, 24 May 2011 06:02:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RznNgLuqm5If for ; Tue, 24 May 2011 06:02:40 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by ietfa.amsl.com (Postfix) with ESMTP id 6431EE066A for ; Tue, 24 May 2011 06:02:40 -0700 (PDT) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4OCOYwU026614 for ; Tue, 24 May 2011 08:24:34 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4OCjYEO124082 for ; Tue, 24 May 2011 08:45:34 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4OCjXUB009853 for ; Tue, 24 May 2011 08:45:34 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-251-50.mts.ibm.com [9.65.251.50]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4OCjWxQ008620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 08:45:32 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4OCjNpk006378; Tue, 24 May 2011 08:45:23 -0400 Message-Id: <201105241245.p4OCjNpk006378@cichlid.raleigh.ibm.com> To: Erik Nordmark Subject: Re: Neighbor Unreachability Detection is too impatient In-reply-to: <4DDAAB85.8000103@acm.org> References: <4DDAAB85.8000103@acm.org> Comments: In-reply-to Erik Nordmark message dated "Mon, 23 May 2011 11:46:29 -0700." Date: Tue, 24 May 2011 08:45:23 -0400 From: Thomas Narten 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: Tue, 24 May 2011 13:02:41 -0000 I support this document. As a general statement, ND has survived for 15 years with relatively few changes from the original specification. We can all take pride in that success. That said, a number of the individual decisions made at that time were somewhat arbitrary, and reflected a view of the world consisting of ethernets (and other LAN technologies) defined by the state-of-the-art available at that time. As systems and technologies have evolved in the last 15 years, some of the boundaries of the ND spec seem worthy of revisiting to take into account what actual deployments are doing today (or will be in the near future). As one example, the cost of multicast on wifi is significantly higher than unicast. Yet, the ND spec calls for deleting an NCE if NUD fails, resulting in a fallback to multicast for address resolution. While this is a simple and straightforward way to make the protocol work, I can imagine worthwhile optimizations whereby ND is more conservative in falling back to multicast and deleting an NCE that was working fine just a few seconds ago. For example, one could continue probing a neighbor using both unicast and multicast, and one could continue to forward traffic to a unicast neighbor vs. discarding it because the NCE has been deleted. I'm sure there are other examples where tweaks to the basic algorithms would be worth considering (so long as they are justified be real operational concerns). Thomas From sowmini.varadhan@oracle.com Tue May 24 06:33:18 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 F29CAE06ED for ; Tue, 24 May 2011 06:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 x4m90zShgeTK for ; Tue, 24 May 2011 06:33:17 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9BCE06BA for ; Tue, 24 May 2011 06:33:17 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p4ODXCt2011122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 May 2011 13:33:14 GMT Received: from quasimodo.us.oracle.com (quasimodo.us.oracle.com [10.152.12.37]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p4ODXBjp027752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 13:33:12 GMT Received: from quasimodo.us.oracle.com (localhost [127.0.0.1]) by quasimodo.us.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p4ODLSUs015424; Tue, 24 May 2011 09:21:28 -0400 (EDT) Received: (from sowmini@localhost) by quasimodo.us.oracle.com (8.14.4+Sun/8.14.4/Submit) id p4ODLRRR015423; Tue, 24 May 2011 09:21:27 -0400 (EDT) X-Authentication-Warning: quasimodo.us.oracle.com: sowmini set sender to sowmini.varadhan@oracle.com using -f Date: Tue, 24 May 2011 09:21:27 -0400 From: sowmini.varadhan@oracle.com To: Erik Nordmark Subject: Re: Neighbor Unreachability Detection is too impatient Message-ID: <20110524132127.GB15274@quasimodo.us.oracle.com> References: <4DDAAB85.8000103@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DDAAB85.8000103@acm.org> User-Agent: Mutt/1.5.21+23 (f7160c94ff70) (2010-12-30) X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4DDBB39A.0147:SCFMA922111,ss=1,fgs=0 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: Tue, 24 May 2011 13:33:18 -0000 On (05/23/11 11:46), Erik Nordmark wrote: > > > This draft proposes to change the requirement that NUD can not retransmit > more than three times, so that NUD can be more robust against temporary > network outages. > > Comments? I think the intention is to use impatient-NUD only when the unicast NS has been triggered by a packet whose IP destination is offlink, i.e., the IP destination is different from the target of the NS, so impatient-NUD should only be applied for router NCE's (and only when the triggering packet has a different IP destination than the NCE target). But if the motivation is to avoid sending mcast NS where possible, it might not be achieved in a few other cases that we can still catch. E.g., even for offlink IP destinations, the switch to an alternative default router might also result in triggering mcast NS if the new router itself has not been resolved yet. If the objective is to avoid sending multicast NS, impatient-NUD would only be useful in reducing mcast traffic if the alternative NCE is in REACHABLE/STALE/PROBE/DELAY state. Would it make sense to REQUIRE impatient-NUD only under that specific circumstance? --Sowmini From jhw@apple.com Tue May 24 09:10: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 5DFF1E073D for ; Tue, 24 May 2011 09:10:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOuaxSjJEfdJ for ; Tue, 24 May 2011 09:10:25 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7408DE06A3 for ; Tue, 24 May 2011 09:10:25 -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 <0LLP00A8GJIIMCP0@mail-out.apple.com> for ipv6@ietf.org; Tue, 24 May 2011 09:10:24 -0700 (PDT) X-AuditID: 11807130-b7c15ae000005aca-e1-4ddbd870d3a9 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 1B.B4.23242.078DBDD4; Tue, 24 May 2011 09:10:24 -0700 (PDT) Received: from [66.109.105.147] (unknown [66.109.105.147]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LLP00LC7JLAFB50@koseret.apple.com> for ipv6@ietf.org; Tue, 24 May 2011 09:10:24 -0700 (PDT) Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: james woodyatt In-reply-to: <201105232348.p4NNmqHJ015491@cichlid.raleigh.ibm.com> Date: Tue, 24 May 2011 09:10:21 -0700 Message-id: References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <201105232348.p4NNmqHJ015491@cichlid.raleigh.ibm.com> To: 6MAN X-Mailer: Apple Mail (2.1227) X-Brightmail-Tracker: AAAAAA== 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, 24 May 2011 16:10:26 -0000 On May 23, 2011, at 4:48 PM, Thomas Narten wrote: > > The one downside is that you run DHCP even if there are no DHCP servers. In some environments, that is extra traffic the operator might not want. I recall many long threads about how the cost of those extra DHCP packets on a wireless network were unacceptable. Yes, and if we'd like to rehash those arguments again, then I stand ready to defend that proposition. -- james woodyatt member of technical staff, core os networking From nordmark@acm.org Tue May 24 09:36: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 20388E0764 for ; Tue, 24 May 2011 09:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] 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 bYBrh7r8cZZ5 for ; Tue, 24 May 2011 09:36:19 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 52D91E0752 for ; Tue, 24 May 2011 09:36:19 -0700 (PDT) Received: from [171.70.217.188] (dhcp-171-70-217-188.cisco.com [171.70.217.188]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p4OGaFMl012582 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 09:36:16 -0700 Message-ID: <4DDBDE7F.5070706@acm.org> Date: Tue, 24 May 2011 09:36:15 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Philip Homburg Subject: Re: Neighbor Unreachability Detection is too impatient References: In-Reply-To: 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: Tue, 24 May 2011 16:36:20 -0000 On 5/23/11 12:09 PM, Philip Homburg wrote: > In your letter dated Mon, 23 May 2011 11:46:29 -0700 you wrote: >> This draft proposes to change the requirement that NUD can not >> retransmit more than three times, so that NUD can be more robust against >> temporary network outages. >> >> Comments? > > Do you have more data on how this problem actually shows up practice? One place where is shows up is when you have a stable network where the routers and hosts have neighbor cache entries for the peers they talk to. But then there is a short outage on the LAN, e.g., due to a switch or link failure causing spanning tree to recalculate things. Should e.g., the router start NUD at that point in time, then NUD is likely to discard the Neighbor Cache entries before STP is done. Thus impact of the STP recalculation gets a lot worse, especially if this is in a massively scaled datacenter. > The draft suggests that the main difference is more multicast traffic. > > How many hosts do you need to have on a single link for this to significantly > impact the performance of the link? Even if there are only two hosts, the issue is that the effect of an event like a STP recalculation expands due to NUD. We don't have that behavior with IPv4/ARP since it doesn't mandate short timeouts. Erik From nordmark@acm.org Tue May 24 09:39: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 6E92EE073D for ; Tue, 24 May 2011 09:39:39 -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=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 WvwU0UesHL+h for ; Tue, 24 May 2011 09:39:38 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id EB838E073C for ; Tue, 24 May 2011 09:39:38 -0700 (PDT) Received: from [171.70.217.188] (dhcp-171-70-217-188.cisco.com [171.70.217.188]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p4OGda1u015995 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 09:39:36 -0700 Message-ID: <4DDBDF48.80606@acm.org> Date: Tue, 24 May 2011 09:39:36 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Wes Beebee Subject: Re: Neighbor Unreachability Detection is too impatient References: In-Reply-To: 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: Tue, 24 May 2011 16:39:39 -0000 On 5/23/11 12:25 PM, Wes Beebee wrote: > Erik, > > I have seen NUD packets dropped during congestion, and for traffic to > periodically drop out for re-resolution. I agree with the goal of making > NUD more robust. However, there may be other approaches besides > retransmitting more times. Agreed. For instance, it makes sense to consider whether the Address Registration option in draft-ietf-6lowpan-nd is something that should be applied outside of 6lowpan. However, such approaches imply a change to hosts and routers. Relaxing the constraints on the ND retransmissions is something which doesn't require a coordinated rollout of router and host changes. Hence I think we need to relax the retransmission constraints now, while looking at future directions. Erik > - Wes > > On 5/23/11 2:46 PM, "Erik Nordmark" wrote: > >> >> This draft proposes to change the requirement that NUD can not >> retransmit more than three times, so that NUD can be more robust against >> temporary network outages. >> >> Comments? >> >> Erik >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-nordmark-6man-impatient-nud-00.txt >> Date: Mon, 23 May 2011 11:43:16 -0700 >> From: internet-drafts@ietf.org >> To: nordmark@cisco.com >> CC: nordmark@cisco.com >> >> A new version of I-D, draft-nordmark-6man-impatient-nud-00.txt has been >> successfully submitted by Erik Nordmark and posted to the IETF repository. >> >> Filename: draft-nordmark-6man-impatient-nud >> Revision: 00 >> Title: Neighbor Unreachability Detection is too impatient >> Creation date: 2011-05-23 >> WG ID: Individual Submission >> Number of pages: 5 >> >> Abstract: >> IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. >> That function is very useful when a host has an alternative, for >> instance multiple default routers, since it allows the host to switch >> to the alternative in short time. This time is 3 seconds after the >> node starts probing. However, if there are no alternatives, this is >> far too impatient. This document proposes an approach where an >> implementation can choose the timeout behavior to be different based >> on whether or not there are alternatives. >> >> >> >> >> >> The IETF Secretariat >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From nordmark@acm.org Tue May 24 09:50:12 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 88E74E073D for ; Tue, 24 May 2011 09:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 X9i7QVhG2tFT for ; Tue, 24 May 2011 09:50:12 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 08BECE0730 for ; Tue, 24 May 2011 09:50:12 -0700 (PDT) Received: from [171.70.217.188] (dhcp-171-70-217-188.cisco.com [171.70.217.188]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p4OGo6n6018737 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 09:50:07 -0700 Message-ID: <4DDBE1BF.7040104@acm.org> Date: Tue, 24 May 2011 09:50:07 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ray Hunter Subject: Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt References: <4DDABDA6.2070705@globis.net> In-Reply-To: <4DDABDA6.2070705@globis.net> 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: Tue, 24 May 2011 16:50:12 -0000 On 5/23/11 1:03 PM, Ray Hunter wrote: > re: http://tools.ietf.org/html/draft-nordmark-6man-impatient-nud-00 > > I'm afraid have more questions than answers. > > Are there any implications for different nodes having different NUD > timeout behavior on a link, and this no longer being symmetrical? No - the reachability state in RFC 4861 is unidirectional. This can easily happen today on a host when TCP provides reachability confirmations to the IP stack, which just indicates forward reachability to the nexthop router. The return traffic might arrive to the host from a different router. > If I can think of two examples...... > > e.g. 1. Say Node A (router) declares node C (end node) unreachable but > Node B (alternate back up router) has not yet timed out node C? > > I'm guessing this case is just like a split-brain segment, so is not > significant compared to existing failures. > > Now the case of router failover.... > > e.g. 2. Say Node A (end host) declares node B (router) unreachable > locally, but node B (router) is still up and running but has not yet > timed out Node A. > > Is that significant? I suspect so. After all if the raison d'etre of > changing NUD timers is to quicken / slow down router failover, surely > Node B (the router) also has to time out at the same speed as the end > host (Node A) otherwise the router will continue to advertise valid > routes to node A, and packets will black hole/queue anyway until NUD on > node B also notices the failure. Are you assuming that the routers inject host routes into the routing system based on the ND state? The routers inject a route for the subnet prefix which isn't tied to the ND state in any way. (If you look at 6lowpan plus roll you'll see a different behavior, which is part of the reason for having explicit host registration in draft-ietf-6lowpan-nd.) > Vice versa is also true, if the router notices the failure first, but > the end node does not react to the failure and hangs around retrying > NUD, packets may queue/black hole in the other direction. > > In the good old days we had things like gratuitous ARP for such events > to attempt to wake up end nodes to refresh their cache, but if they got > lost in some layer 2 STP thrashing it didn't help much anyway. > > Is there thus a need for any over-ridden NUD parameters to be > synchronized across all nodes on a link e.g. via RA messages? No. > Is there a minimum and maximum timeout needed? To prevent danger of an > update storm [as specified in RFC2461 that all Neighbor Solicitations > are rate-limited on a per-neighbor basis] or "stuck in stale". A rate limit makes sense. RFC 4861 already has this with one per second. If ND retransmits more than three times it probably makes sense to recommend binary exponential backoff for the timer. Erik > regards, > RayH > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nordmark@acm.org Tue May 24 10:05:25 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 A5478E0686 for ; Tue, 24 May 2011 10:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 edrQ2i+BOeml for ; Tue, 24 May 2011 10:05:25 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 431F0E0684 for ; Tue, 24 May 2011 10:05:24 -0700 (PDT) Received: from [171.70.217.188] (dhcp-171-70-217-188.cisco.com [171.70.217.188]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p4OH5L9L010391 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 10:05:21 -0700 Message-ID: <4DDBE552.4070603@acm.org> Date: Tue, 24 May 2011 10:05:22 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Thomas Narten Subject: Re: Neighbor Unreachability Detection is too impatient References: <4DDAAB85.8000103@acm.org> <201105241245.p4OCjNpk006378@cichlid.raleigh.ibm.com> In-Reply-To: <201105241245.p4OCjNpk006378@cichlid.raleigh.ibm.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: Tue, 24 May 2011 17:05:25 -0000 On 5/24/11 5:45 AM, Thomas Narten wrote: > I support this document. Thanks. > As one example, the cost of multicast on wifi is significantly higher > than unicast. Yet, the ND spec calls for deleting an NCE if NUD fails, > resulting in a fallback to multicast for address resolution. While > this is a simple and straightforward way to make the protocol work, I > can imagine worthwhile optimizations whereby ND is more conservative > in falling back to multicast and deleting an NCE that was working fine > just a few seconds ago. For example, one could continue probing a > neighbor using both unicast and multicast, and one could continue to > forward traffic to a unicast neighbor vs. discarding it because the > NCE has been deleted. Agreed. The key thing is that when there is a choice (a host with multiple default routers and perhaps a NCE created by a redirect) that the failure of NUD cause it to try an alternative. But if there is no such choice, keeping the NCE around and using it, while trying multicast NS packets, makes a lot of sense. Even if there is a choice, it can make sense to keep the NCE around but marked as UNREACHABLE, if that makes it easier to recover. Should I add your suggestion to the draft? Erik From shemant@cisco.com Tue May 24 10:09: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 602E6E076F for ; Tue, 24 May 2011 10:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 hSHczjU2Lq5D for ; Tue, 24 May 2011 10:09:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8CFE073C for ; Tue, 24 May 2011 10:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1986; q=dns/txt; s=iport; t=1306256988; x=1307466588; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=c6nhmyv52uU8+GP2COhK0u329shERDi9Ldv5cy4uu/c=; b=P8ARxd/j6hQLtJhXoUcEfLGVZLVZKIpQfZ21TU+/Vf7bVajLQtnEYH1o CtP92T1IVYKRUEFyNNRGJcgzMBZY8jOYE46HawqBlls2O7abxQ0yMbrnp 0ygqonVEl4CUia1Kj1ogsz+yuF3QwcqzvRL4PBzkVJYG4iRup5O9K0Rh3 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhABABXl202tJXG+/2dsb2JhbACXZY5Ed6t1nXeGGwSGVo4GimI X-IronPort-AV: E=Sophos;i="4.65,262,1304294400"; d="scan'208";a="702586317" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-6.cisco.com with ESMTP; 24 May 2011 17:09:36 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4OH9Ztx030606; Tue, 24 May 2011 17:09:35 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 12:09:35 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Neighbor Unreachability Detection is too impatient Date: Tue, 24 May 2011 12:09:33 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C301BFF2F2@XMB-RCD-109.cisco.com> In-Reply-To: <4DDAAB85.8000103@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Neighbor Unreachability Detection is too impatient Thread-Index: AcwZeh9GKDZj7yIeSBSCrxLY6K4fxwAux8IQ References: <4DDAAB85.8000103@acm.org> From: "Hemant Singh (shemant)" To: "Erik Nordmark" , X-OriginalArrivalTime: 24 May 2011 17:09:35.0441 (UTC) FILETIME=[5B4F3C10:01CC1A35] 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, 24 May 2011 17:09:51 -0000 I support this document. I will send minor edits directly to the author. Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Erik Nordmark Sent: Monday, May 23, 2011 2:46 PM To: ipv6@ietf.org Subject: Neighbor Unreachability Detection is too impatient This draft proposes to change the requirement that NUD can not=20 retransmit more than three times, so that NUD can be more robust against temporary network outages. Comments? Erik -------- Original Message -------- Subject: New Version Notification for=20 draft-nordmark-6man-impatient-nud-00.txt Date: Mon, 23 May 2011 11:43:16 -0700 From: internet-drafts@ietf.org To: nordmark@cisco.com CC: nordmark@cisco.com A new version of I-D, draft-nordmark-6man-impatient-nud-00.txt has been=20 successfully submitted by Erik Nordmark and posted to the IETF repository. Filename: draft-nordmark-6man-impatient-nud Revision: 00 Title: Neighbor Unreachability Detection is too impatient Creation date: 2011-05-23 WG ID: Individual Submission Number of pages: 5 Abstract: IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative, for instance multiple default routers, since it allows the host to switch to the alternative in short time. This time is 3 seconds after the node starts probing. However, if there are no alternatives, this is far too impatient. This document proposes an approach where an implementation can choose the timeout behavior to be different based on whether or not there are alternatives. =20 The IETF Secretariat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From pch-b2B3A6689@u-1.phicoh.com Tue May 24 10:12: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 F012EE073C for ; Tue, 24 May 2011 10:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 xAGkKgJRpWUF for ; Tue, 24 May 2011 10:12:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 29180E067F for ; Tue, 24 May 2011 10:12:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QOv9u-0001hgC; Tue, 24 May 2011 19:12:42 +0200 Message-Id: To: Erik Nordmark Subject: Re: Neighbor Unreachability Detection is too impatient From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <4DDBDE7F.5070706@acm.org> In-reply-to: Your message of "Tue, 24 May 2011 09:36:15 -0700 ." <4DDBDE7F.5070706@acm.org> Date: Tue, 24 May 2011 19:12:41 +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: Tue, 24 May 2011 17:12:49 -0000 In your letter dated Tue, 24 May 2011 09:36:15 -0700 you wrote: >One place where is shows up is when you have a stable network where the >routers and hosts have neighbor cache entries for the peers they talk >to. But then there is a short outage on the LAN, e.g., due to a switch >or link failure causing spanning tree to recalculate things. Should >e.g., the router start NUD at that point in time, then NUD is likely to >discard the Neighbor Cache entries before STP is done. > >Thus impact of the STP recalculation gets a lot worse, especially if >this is in a massively scaled datacenter. I'm surprised STP traffic has such a low priority that it is actually affected by multicast traffic. But if that's the case, then I guess that changing the NUD paramters to something that takes more than 6 seconds would be a good idea. But that effect can also be obtained by setting the Retrans Timer field in the RA message to 3000ms or more. From nordmark@acm.org Tue May 24 10:15: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 36E14E078A for ; Tue, 24 May 2011 10:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 FmncbbXpKWEh for ; Tue, 24 May 2011 10:15:40 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id B0091E0786 for ; Tue, 24 May 2011 10:15:40 -0700 (PDT) Received: from [171.70.217.188] (dhcp-171-70-217-188.cisco.com [171.70.217.188]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p4OHFcm5013775 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 10:15:38 -0700 Message-ID: <4DDBE7BB.7050205@acm.org> Date: Tue, 24 May 2011 10:15:39 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: sowmini.varadhan@oracle.com Subject: Re: Neighbor Unreachability Detection is too impatient References: <4DDAAB85.8000103@acm.org> <20110524132127.GB15274@quasimodo.us.oracle.com> In-Reply-To: <20110524132127.GB15274@quasimodo.us.oracle.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: Tue, 24 May 2011 17:15:41 -0000 On 5/24/11 6:21 AM, sowmini.varadhan@oracle.com wrote: > I think the intention is to use impatient-NUD only when the unicast NS > has been triggered by a packet whose IP destination is offlink, i.e., > the IP destination is different from the target of the NS, so > impatient-NUD should only be applied for router NCE's (and only when > the triggering packet has a different IP destination than the NCE target). For an off-link destination, if there is only one choice (one default router) there is no need to be impatient. Thus the applicability of patience is a bit broader. > But if the motivation is to avoid sending mcast NS where possible, it might > not be achieved in a few other cases that we can still catch. > E.g., even for offlink IP destinations, the switch to an alternative > default router might also result in triggering mcast NS if the new > router itself has not been resolved yet. If the objective is to avoid > sending multicast NS, impatient-NUD would only be useful in reducing > mcast traffic if the alternative NCE is in REACHABLE/STALE/PROBE/DELAY > state. Would it make sense to REQUIRE impatient-NUD only under that > specific circumstance? If a host has multiple default routers, it is likely (but not required by RFC 4861) that the host sends some flows to the different default routers. In that case there is an NCE for each default router. Thus declaring one of them as unreachable and moving those flows to use a different default router doesn't cause additional multicasts. Erik From nordmark@acm.org Tue May 24 10:22:12 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 6CB3813000C for ; Tue, 24 May 2011 10:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.799 X-Spam-Level: X-Spam-Status: No, score=-103.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] 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 flZoai--qW1j for ; Tue, 24 May 2011 10:22:12 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id E7F5F130013 for ; Tue, 24 May 2011 10:22:11 -0700 (PDT) Received: from [171.70.217.188] (dhcp-171-70-217-188.cisco.com [171.70.217.188]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p4OHM8Jo020669 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 10:22:09 -0700 Message-ID: <4DDBE941.8030007@acm.org> Date: Tue, 24 May 2011 10:22:09 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Philip Homburg Subject: Re: Neighbor Unreachability Detection is too impatient References: <4DDBDE7F.5070706@acm.org> In-Reply-To: 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: Tue, 24 May 2011 17:22:12 -0000 On 5/24/11 10:12 AM, Philip Homburg wrote: > In your letter dated Tue, 24 May 2011 09:36:15 -0700 you wrote: >> One place where is shows up is when you have a stable network where the >> routers and hosts have neighbor cache entries for the peers they talk >> to. But then there is a short outage on the LAN, e.g., due to a switch >> or link failure causing spanning tree to recalculate things. Should >> e.g., the router start NUD at that point in time, then NUD is likely to >> discard the Neighbor Cache entries before STP is done. >> >> Thus impact of the STP recalculation gets a lot worse, especially if >> this is in a massively scaled datacenter. > > I'm surprised STP traffic has such a low priority that it is actually affected > by multicast traffic. That isn't the issue. During the STP topology change bridges go into blocking state for some amount of time. This causes packets to be dropped. If this last for more than 3 seconds, and a NUD probe is started at that point, then the three *unicast* NS messages that are used for NUD are all dropped. With current RFC 4861 this means that the NCE has to be discarded, since the neighbor is deemed UNREACHABLE. Without the NCE, the next time the node tries to send a packet, it will end up multicasting NS messages. Erik > But if that's the case, then I guess that changing the NUD paramters to > something that takes more than 6 seconds would be a good idea. > > But that effect can also be obtained by setting the Retrans Timer field in > the RA message to 3000ms or more. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From shemant@cisco.com Tue May 24 10:27:07 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 ECED0130027 for ; Tue, 24 May 2011 10:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 gtDvvpYnKRu1 for ; Tue, 24 May 2011 10:27:06 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 505E0130023 for ; Tue, 24 May 2011 10:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7128; q=dns/txt; s=iport; t=1306258026; x=1307467626; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=b6p3J1UpZy/LeG5NJWBXkZNePtnkIysynvExDPZBVxA=; b=DIytsH5bfU1nLQ27t7+XgcEk9F3v2yD7Th+Olsh/YXE/vcDQdETChe6m K451BSxR216zuOHZw5ro8igRjYZ7LSKujDUJ47EEoJF/54rTJPHKdTlIF XoXRiHSaymQCqbs2KGgK1sspQPAR6FX1nx3a+NLQ0u8qRCYDjDjjzQLEU E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0BAKPp202tJXG8/2dsb2JhbACCZpR/jkR3q3adeoYbBIZWjgaKYg X-IronPort-AV: E=Sophos;i="4.65,262,1304294400"; d="scan'208,217";a="453472314" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-1.cisco.com with ESMTP; 24 May 2011 17:27:05 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4OHR53g029957; Tue, 24 May 2011 17:27:05 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 12:27:05 -0500 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_01CC1A37.CCD7F358" Subject: RE: Neighbor Unreachability Detection is too impatient Date: Tue, 24 May 2011 12:27:06 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C301BFF311@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Neighbor Unreachability Detection is too impatient Thread-Index: AcwZglpAH9PxBC/+TRSbWZMgzq2+9AAswT3Q References: <4DDAAB85.8000103@acm.org> From: "Hemant Singh (shemant)" To: "Mark Townsley" , "Erik Nordmark" X-OriginalArrivalTime: 24 May 2011 17:27:05.0166 (UTC) FILETIME=[CCFE8EE0:01CC1A37] 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: Tue, 24 May 2011 17:27:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1A37.CCD7F358 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Mark Townsley Sent: Monday, May 23, 2011 3:47 PM To: Erik Nordmark Cc: ipv6@ietf.org Subject: Re: Neighbor Unreachability Detection is too impatient =20 =20 >In short, NUD thought that a host which was in the neighbor cache really wasn't available (due to incorrect FW blocking at the host) removed it from the neighbor cache and started dropping packets (and causing timeouts in gmail). In test, it took about >8 pings for the problem to manifest (time for NUD to retry enough to fail), which was followed by the classic IPv6 to IPv4 failover by the host (Windows Vista).=20 =20 In your test did you see how many NUD probes were sent out when eight pings were sent? The reason I am asking the question is because the unicast NUD messages have to cap at three. In so many pings, I wouldn't be surprised if the host also issues an address resolution multicast NS. =20 =20 >Also, the Broadband Forum's WT-146 (which isn't a public document, but if you are BBF member you can take a look at it) specifies NUD as a monitoring mechanism for "IPv6 sessions" over access links (which ultimately may be tied into billing, >alerts, etc.). =20 Note with this document's proposal and if the BBF access link has no alternative, the BBF nodes would have to implement NUD probing for a longer time. Alternatively, one could use BFD for monitoring.=20 =20 Hemant =20 ------_=_NextPart_001_01CC1A37.CCD7F358 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From:= ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = Mark Townsley
Sent: Monday, May 23, 2011 3:47 PM
To: Erik Nordmark
Cc: ipv6@ietf.org
Subject: Re: Neighbor Unreachability Detection is too = impatient

 

 

>In short, = NUD thought that a host which was in the neighbor cache really wasn't available (due = to incorrect FW blocking at the host) removed it from the neighbor cache = and started dropping packets (and causing timeouts in gmail). In test, it = took about >8 pings for the problem = to manifest (time for NUD to retry enough to fail), which was followed by = the classic IPv6 to IPv4 failover by the host (Windows = Vista). 

 

In your test did you see how many NUD probes were sent = out when eight pings were sent?  The reason I am asking the question is = because the unicast NUD messages have to cap at three.    In so many = pings, I wouldn’t be surprised if the host also issues an address = resolution multicast NS.  

 

>Also, the = Broadband Forum's WT-146 (which isn't a public document, but if you are BBF member = you can take a look at it)  specifies NUD as a monitoring mechanism for "IPv6 sessions" over access links (which ultimately may be = tied into billing, >alerts, etc.).

 

Note with this document’s proposal  and if the = BBF access link has no alternative, the BBF nodes would have to implement = NUD probing for a longer time.  Alternatively, one could use BFD for monitoring.

 

Hemant

 

------_=_NextPart_001_01CC1A37.CCD7F358-- From nordmark@acm.org Tue May 24 10:45:56 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 01810E0782 for ; Tue, 24 May 2011 10:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 SUg6Z1EhiZuh for ; Tue, 24 May 2011 10:45:55 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 75A0AE077B for ; Tue, 24 May 2011 10:45:55 -0700 (PDT) Received: from [171.70.217.188] (dhcp-171-70-217-188.cisco.com [171.70.217.188]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p4OHjnVN013564 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 10:45:50 -0700 Message-ID: <4DDBEECF.2010307@acm.org> Date: Tue, 24 May 2011 10:45:51 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Philip Homburg Subject: Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt References: <4DDACD31.9020602@globis.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ray Hunter , 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: Tue, 24 May 2011 17:45:56 -0000 On 5/23/11 2:22 PM, Philip Homburg wrote: > But for relatively stable links consisting of just BGP peers, it may make more > sense to just hardwire the ND entries and disable ND. FWIW RFC 4861 allows for this. Section 7.3 says: Neighbor Unreachability Detection is used for all paths between hosts and neighboring nodes, including host-to-host, host-to-router, and router-to-host communication. Neighbor Unreachability Detection may also be used between routers, but is not required if an equivalent mechanism is available, for example, as part of the routing protocols. Erik From Fred.L.Templin@boeing.com Tue May 24 10:51: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 54D79E073D for ; Tue, 24 May 2011 10:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 yM7YyoIM3iAz for ; Tue, 24 May 2011 10:51:31 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id C7CA6E067F for ; Tue, 24 May 2011 10:51:31 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4OHpP46017843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 May 2011 12:51:28 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p4OHpOxH025242; Tue, 24 May 2011 10:51:24 -0700 (PDT) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4OHpFD4024832 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 24 May 2011 10:51:16 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Tue, 24 May 2011 10:51:15 -0700 From: "Templin, Fred L" To: Thomas Narten , "Brzozowski, John" Date: Tue, 24 May 2011 10:51:14 -0700 Subject: RE: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AcwZhYqpNxrnfZgCRvibfhLVeAoBrQAtXSdA Message-ID: References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> In-Reply-To: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bob Hinden , "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: Tue, 24 May 2011 17:51:32 -0000 Hi Thomas,=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Thomas Narten > Sent: Monday, May 23, 2011 1:11 PM > To: Brzozowski, John > Cc: ipv6@ietf.org; Bob Hinden > Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD >=20 > > Is the intention for the new text to relax the requirement for > > auto-configuration? >=20 > No. SLAAC remains a MUST. DHCPv6 though is now a SHOULD. >=20 > For one thing, DHCP doesn't have an option configure on-link prefixes, > so we still need SLAAC. Not all links will necessarily require on-link prefixes. For those, DHCPv6 alone may be sufficient. Thanks - Fred fred.l.templin@boeing.com > What we should have done oh-so-long-ago is ensure that you could > configure/operate a network with just DHCP (and no SLAAC at all) and > vice versa, and than made both a MUST on hosts. That way, operators > truly have the choice as to which to use and everything would just > work. >=20 > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = From v6ops@globis.net Tue May 24 11:33: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 41D7DE0765 for ; Tue, 24 May 2011 11:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.774 X-Spam-Level: X-Spam-Status: No, score=-2.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599] 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 cgbFKvpJEAxm for ; Tue, 24 May 2011 11:33:21 -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 3A6A4E06C0 for ; Tue, 24 May 2011 11:33:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C37D6870086; Tue, 24 May 2011 20:33:18 +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 QcU0KFv4f6ma; Tue, 24 May 2011 20:33:13 +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 91E77870082; Tue, 24 May 2011 20:33:13 +0200 (CEST) Message-ID: <4DDBF9E9.1040702@globis.net> Date: Tue, 24 May 2011 20:33:13 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Erik Nordmark Subject: Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt References: <4DDABDA6.2070705@globis.net> <4DDBE1BF.7040104@acm.org> In-Reply-To: <4DDBE1BF.7040104@acm.org> 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: Tue, 24 May 2011 18:33:22 -0000 Thanks very much for replying. I think that I understand the motivation in that multicast is expensive on some media, and that you thus want to avoid it. I'm always prepared to be dazzled by my lack of knowledge or incorrect assumptions. I'd much rather ask a dumb question and get a smart answer than just say nothing. The idea of the draft seems to be that spending more time performing unicast neighbor solicitations in the "probe" state might avoid deleting the neighbor entry, and thus the relearning the entry via "expensive" multicast NS from the "-" state. Seems perfectly reasonable and something worth pursuing. Erik Nordmark wrote: > Are you assuming that the routers inject host routes into the routing > system based on the ND state? The routers inject a route for the > subnet prefix which isn't tied to the ND state in any way. Yes, on the local link the router injects RA information based on a (statically configured or PD learned) prefix. But routers and other devices also redistribute reachability information elsewhere via other protocols. The assumption that ND really is independent of everything else is what I'm questioning myself, although I freely admit to a large dose of hand waving here. ND isn't like ARP, as you of course know. An ARP cache entry would sit there silently for 4 hours by default and do nothing, so packets could black hole if the next hop was learned via a static route. Higher level protocols would have to detect the problem themselves. ND removing an entry by NUD probe failure retriggers next hop determination, and AFAIK also actively triggers replying to remote nodes with an ICMP unreachable message, and so ND can thus can effectively disseminate reachability information far further than just the local link. A later post I made gave an example of reachability info being indirectly based on ND (via a BGP neighbor peering TCP session becoming unreachable due to an ICMPv6 unreachable, leading to route information changing). I can imagine the same for EIGRP, OSPF if their neighbors disappear due to receipt of an ICMPv6 unreachable (although traditionally these implementations have tended to ignore ICMP for good reason). Another example sort of device that sometimes transmist reachability information via TCP are WAN accelerators, that auto build network tunnels, and then send routing information across these. Again, an ICMPv6 unreachable might cause the device to tear down the tunnel. HSRP preference metrics can also potentially be influenced by reachability information (ND) from another link (via track commands). Then there are also those dreaded silent devices (that we don't talk much about but which are generally plonked on the very most critical link into the main data centre), such as network intrusion detection systems and firewalls, that actively monitor traffic across their links, but that don't take part in any official routing protocol exchanges, and can fail over to a back up system without informing anyone else by marking interfaces up and down. Using the example of spanning tree, waiting for STP would probably mean waiting 35 seconds (max_age + forwarding delay) in the default case for the root bridge to send out topology notification BPDU's. That's a long time in many protocols. So I guess the question is also, do you want NUD to inform higher layers of the need for a fail over ASAP of a local link failure via ICMP unreachables (as Thomas seemed to suggest), or do you want ND to shut up and just keep on retrying locally and let those higher layer protocols hit their own time outs and take their own fail over actions? Current ND seems to go the ASAP route with its 3 second timeout. Historically, ARP seems to go the silent route. It just feels to me like all nodes on a common link should behave the same way in this respect (no scientific argument, just raw gut feeling of deja vu, and impending packet storms) And if all nodes on the link aren't behaving the same way, don't you still get say 50% of the multicasts as the partner nodes revert to the "-" state by timing out "too fast" for that link type? Just seems like another reason to have this as a "per link" parameter rather than a "per node" parameter. Best regards, RayH From Christopher.Palmer@microsoft.com Tue May 24 12:14: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 0E41FE078C for ; Tue, 24 May 2011 12:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 B2esWp4xhi-S for ; Tue, 24 May 2011 12:14:44 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 559D7E0766 for ; Tue, 24 May 2011 12:14:44 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 24 May 2011 12:14:44 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 24 May 2011 12:14:43 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.165]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Tue, 24 May 2011 12:14:43 -0700 From: Christopher Palmer To: Thomas Narten , "ipv6@ietf.org" Subject: RE: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AQHMEXM17gaeoL7OlkGBmbXATPr1DJScaaTg Date: Tue, 24 May 2011 19:14:42 +0000 Message-ID: <0AB09EDBCD1C484EBE45978D62F3513C3CE1881B@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> In-Reply-To: <201105131337.p4DDbdao009901@cichlid.raleigh.ibm.com> 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 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, 24 May 2011 19:14:45 -0000 Very long thread.... I simply wanted to signal our (Windows Networking) support of DHCPv6 being = a SHOULD, and I personally think the text below is entirely good. ---------------------------- Christopher.Palmer@Microsoft.com=20 Program Manager=20 IPv6 @ Windows -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Tho= mas Narten Sent: Friday, May 13, 2011 6:38 AM To: ipv6@ietf.org Subject: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Per a previous thread, there are indications that the WG may now be willing= to recommend that DHCPv6 be a SHOULD for all hosts. This is based on the f= ollowing rationale: Thomas Narten writes: > I personally would support having DHCP be a SHOULD rather than a MAY.=20 > The justification in my mind is that if you want the network operator=20 > to have the choice of whether they want to use Stateless addrconf OR=20 > DHCP, they only have that choice of devices widely implement both. This was supported by some others, particularly now that it is clear there = are more implementations of DHCPv6, e.g.: Bob Hinden writes: > While my personal view is that DHCPv6 won't be used for host=20 > configuration in cable/DSL deployments (except for provisioning the=20 > prefix to the home router), it appears that DHCPv6 is being widely=20 > implemented in host OS's because it is needed some environments. > There are enough variations in deployment models that a host developer=20 > will need to support both. > Based on this, I think a SHOULD is OK.=20 Let me propose the following change be made to the node requirements document: OLD/Current: DHCP can be used to obtain and configure addresses. In general, a network may provide for the configuration of addresses through Router Advertisements, DHCP or both. At the present time, the configuration of addresses via stateless autoconfiguration is more widely implemented in hosts than address configuration via DHCP. However, some environments may require the use of DHCP and may not support the configuration of addresses via RAs. Implementations should be aware of what operating environment their devices will be deployed. Hosts MAY implement address configuration via DHCP. New: DHCPv6 can be used to obtain and configure addresses. In general, a network may provide for the configuration of addresses through Router Advertisements, DHCPv6 or both. Some operators have indicated that they do not intend to support stateless address autoconfiguration on their networks and will require all address assignments be made through DHCPv6. On such networks, devices that support only stateless address autoconfiguration will be unable to automatically configure addresses. Consequently all hosts SHOULD implement address configuration via DHCP. Is this acceptable? Please respond yes or no. Given the WG's previous hesitation to having DHCPv6 be a SHOULD, it is important that we get a clear indication of wheth= er or not the WG supports this change. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From john.loughney@nokia.com Tue May 24 12:18: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 C23C3E0770 for ; Tue, 24 May 2011 12:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 YI-Mm6tBST0P for ; Tue, 24 May 2011 12:18:17 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B6CFCE0766 for ; Tue, 24 May 2011 12:18:16 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p4OJIBGC017881; Tue, 24 May 2011 22:18:12 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 May 2011 22:18:07 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 24 May 2011 21:18:05 +0200 Received: from 008-AM1MPN1-003.mgdnok.nokia.com ([169.254.3.183]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0289.008; Tue, 24 May 2011 21:18:05 +0200 From: To: , Subject: RE: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AQHMGaNa47acKhysyUK96EyXP2xcCpSa8yIAgAESOYCAAFWLkA== Date: Tue, 24 May 2011 19:18:04 +0000 Message-ID: <1571128F4B736C42B743F492521F123B204C71@008-AM1MPN1-003.mgdnok.nokia.com> References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <201105232348.p4NNmqHJ015491@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.162.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 24 May 2011 19:18:07.0245 (UTC) FILETIME=[4FE723D0:01CC1A47] X-Nokia-AV: Clean 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, 24 May 2011 19:18:17 -0000 Dumb question, but isn't the text making support for DHCPv6 a SHOULD, but n= ot making it a SHOULD or MUST to run?=20 I completely agree that in some networks (or interfaces) where the node 'kn= ows' that DHCP isn't deployed in the network, there is no sense in running = DHCP. -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of ext= james woodyatt Sent: Tuesday, May 24, 2011 9:10 AM To: 6MAN Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD On May 23, 2011, at 4:48 PM, Thomas Narten wrote: >=20 > The one downside is that you run DHCP even if there are no DHCP servers. = In some environments, that is extra traffic the operator might not want. I = recall many long threads about how the cost of those extra DHCP packets on = a wireless network were unacceptable. Yes, and if we'd like to rehash those arguments again, then I stand ready t= o defend that proposition. -- james woodyatt member of technical staff, core os networking -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From narten@us.ibm.com Tue May 24 13:14:49 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 3964CE07DF for ; Tue, 24 May 2011 13:14:49 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7d+Vn3CtUBdB for ; Tue, 24 May 2011 13:14:48 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB0AE07C6 for ; Tue, 24 May 2011 13:14:48 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4OK21dO029314 for ; Tue, 24 May 2011 14:02:01 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p4OKEGfc132820 for ; Tue, 24 May 2011 14:14:19 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4OEEAa6011736 for ; Tue, 24 May 2011 08:14:10 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-251-50.mts.ibm.com [9.65.251.50]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4OEE9Nv011589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2011 08:14:10 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4OKE7vW009893; Tue, 24 May 2011 16:14:08 -0400 Message-Id: <201105242014.p4OKE7vW009893@cichlid.raleigh.ibm.com> To: john.loughney@nokia.com Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD In-reply-to: <1571128F4B736C42B743F492521F123B204C71@008-AM1MPN1-003.mgdnok.nokia.com> References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <201105232348.p4NNmqHJ015491@cichlid.raleigh.ibm.com> <1571128F4B736C42B743F492521F123B204C71@008-AM1MPN1-003.mgdnok.nokia.com> Comments: In-reply-to message dated "Tue, 24 May 2011 19:18:04 -0000." Date: Tue, 24 May 2011 16:14:07 -0400 From: Thomas Narten 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: Tue, 24 May 2011 20:14:49 -0000 > Dumb question, but isn't the text making support for DHCPv6 a > SHOULD, but not making it a SHOULD or MUST to run? Correct. It's a SHOULD to implement. Whether to use it is a separate discussion, and neither the Node Requirements or IPv6 specs address this. Thomas From ipng@69706e6720323030352d30312d31340a.nosense.org Tue May 24 14:16: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 928B0E07A6 for ; Tue, 24 May 2011 14:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 w7FkM+nuUPW4 for ; Tue, 24 May 2011 14:16:43 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 10483E0786 for ; Tue, 24 May 2011 14:16:43 -0700 (PDT) Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QOyxn-0004V2-GS; Wed, 25 May 2011 06:46:27 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 404483B338; Wed, 25 May 2011 06:46:27 +0930 (CST) Date: Wed, 25 May 2011 06:46:27 +0930 From: Mark Smith To: "Templin, Fred L" Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Message-ID: <20110525064627.7f1f7746@opy.nosense.org> In-Reply-To: References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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: Thomas Narten , "ipv6@ietf.org" , Bob Hinden 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, 24 May 2011 21:16:43 -0000 Hi Fred, On Tue, 24 May 2011 10:51:14 -0700 "Templin, Fred L" wrote: > Hi Thomas, > > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > > Behalf Of Thomas Narten > > Sent: Monday, May 23, 2011 1:11 PM > > To: Brzozowski, John > > Cc: ipv6@ietf.org; Bob Hinden > > Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD > > > > > Is the intention for the new text to relax the requirement for > > > auto-configuration? > > > > No. SLAAC remains a MUST. DHCPv6 though is now a SHOULD. > > > > For one thing, DHCP doesn't have an option configure on-link prefixes, > > so we still need SLAAC. > > Not all links will necessarily require on-link prefixes. For > those, DHCPv6 alone may be sufficient. > Out of curiosity, wouldn't link locals be classified as SLAAC addresses (as in, their configuration is stateless and they're autoconfigured by default)? I understand you're saying that there are scenarios where RA's wouldn't contain a PIO, or perhaps the PIO wouldn't have then on-link flag set, however I'm curious if saying that SLAAC isn't necessary in that scenario is also implying that link-locals may not be necessary either? Thanks, Mark. From brian.e.carpenter@gmail.com Tue May 24 14:17: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 9A4A5E07BA for ; Tue, 24 May 2011 14:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Qyll8bmv5S6p for ; Tue, 24 May 2011 14:17:45 -0700 (PDT) Received: from mail-px0-f179.google.com (mail-px0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id C59D4E078B for ; Tue, 24 May 2011 14:17:44 -0700 (PDT) Received: by pxi2 with SMTP id 2so4198265pxi.38 for ; Tue, 24 May 2011 14:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=D4JoA6TXdmVguoqKtqYK1LZ+NY5pF/NLUUZYpo3SXx4=; b=El+Xv1hcxmvozz2carcC+MT7F4ujWYecSP8svvTAYbQa+jpVUjF5UlHdlltSOX6ANX E6dUbUr6rmP9AzsNbKVqvmcx7F1HPScQZ/aT5AmB9Um6ll1/xKV7oNIrObeF1/N2JKSo xK+/orFQhU/LCwEMD/3Ok/iGjoHIw6sEkNL7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=YQ63254Ukr5f4vT6lJS1XrFf3JSO1zA6dztAg8L7MS9/LC/Cr1rpcv1dS3oqi05vY3 aLSX7xHADYPF39uN6j547VaWwdqaIgjbjzlWQlo5yr+9wBfzJMNPsR+jU/EKtaZEsIGW B6SwZIv/QM2Wz59SLjq5PxUbYDQ5gLOzj3ANw= Received: by 10.68.57.70 with SMTP id g6mr3081301pbq.511.1306271864573; Tue, 24 May 2011 14:17:44 -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 i7sm5227199pbs.19.2011.05.24.14.17.42 (version=SSLv3 cipher=OTHER); Tue, 24 May 2011 14:17:43 -0700 (PDT) Message-ID: <4DDC2074.6080000@gmail.com> Date: Wed, 25 May 2011 09:17:40 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Narten Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <201105232348.p4NNmqHJ015491@cichlid.raleigh.ibm.com> <1571128F4B736C42B743F492521F123B204C71@008-AM1MPN1-003.mgdnok.nokia.com> <201105242014.p4OKE7vW009893@cichlid.raleigh.ibm.com> In-Reply-To: <201105242014.p4OKE7vW009893@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com, 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: Tue, 24 May 2011 21:17:45 -0000 On 2011-05-25 08:14, Thomas Narten wrote: >> Dumb question, but isn't the text making support for DHCPv6 a >> SHOULD, but not making it a SHOULD or MUST to run? > > Correct. It's a SHOULD to implement. Whether to use it is a separate > discussion, and neither the Node Requirements or IPv6 specs address > this. Which, to repeat myself again, is exactly the point made by RFC 5887. As far as the document currently under discussion is concerned, surely we are done? Brian From ipng@69706e6720323030352d30312d31340a.nosense.org Tue May 24 14:21: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 4187FE07D2 for ; Tue, 24 May 2011 14:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 WbIvGPdfTsPn for ; Tue, 24 May 2011 14:21:36 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 9A010E07BA for ; Tue, 24 May 2011 14:21:35 -0700 (PDT) Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QOz2k-0004eY-Pi; Wed, 25 May 2011 06:51:34 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 848883B338; Wed, 25 May 2011 06:51:34 +0930 (CST) Date: Wed, 25 May 2011 06:51:34 +0930 From: Mark Smith To: "Manfredi, Albert E" Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Message-ID: <20110525065134.59b073a7@opy.nosense.org> In-Reply-To: References: <201105232010 .p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B56419 05@gmail.com> <201105232 111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <4DDADBFD.7000803@gmail.com> <20110524080154.513002bf@opy.nosense.org> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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: Tue, 24 May 2011 21:21:41 -0000 Hi Bert, On Mon, 23 May 2011 18:07:15 -0500 "Manfredi, Albert E" wrote: > Mark Smith wrote: > > > " 3.2 If there are several ways of doing the same thing, choose one. > > If a previous design, in the Internet context or elsewhere, has > > successfully solved the same problem, choose the same solution > > unless > > there is a good technical reason not to. Duplication of the same > > protocol functionality should be avoided as far as possible, without > > of course using this argument to reject improvements." > > > > > > It's shame IPv6 fails on that count. I'm genuinely asking what the > > improvements are to justify why two mechanisms that are almost > > functionally equivalent. > > Mark, as I suggested previously, DHCP is useful in cases where you need the IP addresses of hosts in a network to be predictable. Isn't the best way to achieve predictable addresses to use static ones? Or are you talking about an assured and automated permanent binding between a link layer address and an IPv6 address? If it's the latter then that is the only functionality gap I can think of between SLAAC and DHCPv6, although obviously SLAAC addresses are usually derived from link layer addresses. > I have no idea why cable systems want DHCP, but I'm saying that IN > GENERAL, if hosts needs to know a priori what the address of other > hosts is, SLAAC falls flat on its face. > > For example, a peer-to-peer network, where you don't want to rely on a DNS. > > Bert > Regards, Mark. From Fred.L.Templin@boeing.com Tue May 24 15:00:24 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 4CE19E0785 for ; Tue, 24 May 2011 15:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ZHZ5qwro6Kgo for ; Tue, 24 May 2011 15:00:23 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id C05B6E073C for ; Tue, 24 May 2011 15:00:23 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4OM07dV025410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 May 2011 15:00:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p4OLAg1u018530; Tue, 24 May 2011 14:10:42 -0700 (PDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4OLAdOX018266 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 24 May 2011 14:10:39 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Tue, 24 May 2011 15:00:04 -0700 From: "Templin, Fred L" To: Mark Smith Date: Tue, 24 May 2011 15:00:03 -0700 Subject: RE: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Topic: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Thread-Index: AcwaV+iPr53ap8MOSxiAS03TaYmhLAABZMOw Message-ID: References: <201105232010 .p4NKAV9X012654@cichlid.raleigh.ibm.com> <20110525064627.7f1f7746@opy.nosense.org> In-Reply-To: <20110525064627.7f1f7746@opy.nosense.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "ipv6@ietf.org" , Bob Hinden 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, 24 May 2011 22:00:24 -0000 Hi Mark,=20 > -----Original Message----- > From: Mark Smith=20 > [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org]=20 > Sent: Tuesday, May 24, 2011 2:16 PM > To: Templin, Fred L > Cc: Thomas Narten; Brzozowski, John; Bob Hinden; ipv6@ietf.org > Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD >=20 > Hi Fred, >=20 > On Tue, 24 May 2011 10:51:14 -0700 > "Templin, Fred L" wrote: >=20 > > Hi Thomas,=20 > >=20 > > > -----Original Message----- > > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > > > Behalf Of Thomas Narten > > > Sent: Monday, May 23, 2011 1:11 PM > > > To: Brzozowski, John > > > Cc: ipv6@ietf.org; Bob Hinden > > > Subject: Re: Node Requirements: Elevating DHCPv6 from MAY=20 > to SHOULD > > >=20 > > > > Is the intention for the new text to relax the requirement for > > > > auto-configuration? > > >=20 > > > No. SLAAC remains a MUST. DHCPv6 though is now a SHOULD. > > >=20 > > > For one thing, DHCP doesn't have an option configure=20 > on-link prefixes, > > > so we still need SLAAC. > >=20 > > Not all links will necessarily require on-link prefixes. For > > those, DHCPv6 alone may be sufficient. > >=20 >=20 > Out of curiosity, wouldn't link locals be classified as SLAAC > addresses (as in, their configuration is stateless and > they're autoconfigured by default)? I understand you're saying that > there are scenarios where RA's wouldn't contain a PIO, or perhaps the > PIO wouldn't have then on-link flag set, however I'm curious if saying > that SLAAC isn't necessary in that scenario is also implying that > link-locals may not be necessary either? Good point; yes, even DHCPv6 requires link-locals. The link-locals could be manually configured, but it seems reasonable to assume that they would often be autoconfigured using SLAAC. Thanks - Fred fred.l.templin@boeing.com > Thanks, > Mark.= From dougb@dougbarton.us Tue May 24 15:36: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 C1E79E07AB for ; Tue, 24 May 2011 15:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.844 X-Spam-Level: X-Spam-Status: No, score=-3.844 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ZNTsJGUNS2DC for ; Tue, 24 May 2011 15:36:36 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id D4F47E07A7 for ; Tue, 24 May 2011 15:36:35 -0700 (PDT) Received: (qmail 18670 invoked by uid 399); 24 May 2011 22:36:33 -0000 Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 24 May 2011 22:36:33 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DDC32EF.3000507@dougbarton.us> Date: Tue, 24 May 2011 15:36:31 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD References: <201105232010 .p4NKAV9X012654@cichlid.raleigh.ibm.com> <20110525064627.7f1f7746@opy.nosense.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "ipv6@ietf.org" , Bob Hinden 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, 24 May 2011 22:36:36 -0000 On 05/24/2011 15:00, Templin, Fred L wrote: > Good point; yes, even DHCPv6 requires link-locals. The > link-locals could be manually configured, but it seems > reasonable to assume that they would often be autoconfigured > using SLAAC. I'm confused (nothing new about that). In FreeBSD the OS creates the LLA, which is then used for rtsol, etc. Are we doing it wrong? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From pch-b2B3A6689@u-1.phicoh.com Wed May 25 02:10:18 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 E9611E07BC for ; Wed, 25 May 2011 02:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 piK9gEU6kN5U for ; Wed, 25 May 2011 02:10:17 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id D25FDE06D4 for ; Wed, 25 May 2011 02:10:16 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QPA6W-0001hIC; Wed, 25 May 2011 11:10:12 +0200 Message-Id: To: Erik Nordmark Subject: Re: Neighbor Unreachability Detection is too impatient From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <4DDBDE7F.5070706@acm.org> <4DDBE941.8030007@acm.org> In-reply-to: Your message of "Tue, 24 May 2011 10:22:09 -0700 ." <4DDBE941.8030007@acm.org> Date: Wed, 25 May 2011 11:10:10 +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: Wed, 25 May 2011 09:10:19 -0000 In your letter dated Tue, 24 May 2011 10:22:09 -0700 you wrote: >On 5/24/11 10:12 AM, Philip Homburg wrote: >With current RFC 4861 this means that the NCE has to be discarded, since >the neighbor is deemed UNREACHABLE. > >Without the NCE, the next time the node tries to send a packet, it will >end up multicasting NS messages. So you are saying (with a bit exaggeration from my side) that some links in data centers have so many hosts that a network disruption of a few seconds will cause a multicast storm big enough to meltdown the network. With modern CPUs and a Gbit/s network that seems very odd to me. From swmike@swm.pp.se Wed May 25 02:20:53 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 B4B34E0679 for ; Wed, 25 May 2011 02:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 KZ-diLb0ddpF for ; Wed, 25 May 2011 02:20:53 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id C585EE06DF for ; Wed, 25 May 2011 02:20:52 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BE2B19C; Wed, 25 May 2011 11:20:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BBDE59A for ; Wed, 25 May 2011 11:20:49 +0200 (CEST) Date: Wed, 25 May 2011 11:20:49 +0200 (CEST) From: Mikael Abrahamsson To: ipv6@ietf.org Subject: Re: Neighbor Unreachability Detection is too impatient In-Reply-To: Message-ID: References: <4DDBDE7F.5070706@acm.org> <4DDBE941.8030007@acm.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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, 25 May 2011 09:20:53 -0000 On Wed, 25 May 2011, Philip Homburg wrote: > So you are saying (with a bit exaggeration from my side) that some links > in data centers have so many hosts that a network disruption of a few > seconds will cause a multicast storm big enough to meltdown the network. > > With modern CPUs and a Gbit/s network that seems very odd to me. I have an example from reality: At AMSIX, there are a few hundred routers on the same L2 network. Connected to this we have a router from a major well known vendor. This vendor does not filter IPv6 multicast messages on the linecard, but instead punts all of it to RP, and AMSIX L2 infrastructure treats all multicast as broadcast, so all multicast (mainly ND traffic) is sent out on all ports. This traffic to the RP was enough to cause IPv6 BGP sessions to go down because it was continous ND messages coming in all the time (few hundred PPS). ND is chatty, and it does cause problems on large networks. One might call this multiple faults on multiple levels (bad linecard code, bad L2 platform, bad low-performing CPU on the RP), but it does cause problems in real life regardless. -- Mikael Abrahamsson email: swmike@swm.pp.se From ipng@69706e6720323030352d30312d31340a.nosense.org Wed May 25 03:25: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 4CFB0E06FA for ; Wed, 25 May 2011 03:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 S8WvIP-7Up4k for ; Wed, 25 May 2011 03:25:44 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id C275EE0697 for ; Wed, 25 May 2011 03:25:43 -0700 (PDT) Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QPBHN-00022V-CB; Wed, 25 May 2011 19:55:29 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id BF6223B33D; Wed, 25 May 2011 19:55:28 +0930 (CST) Date: Wed, 25 May 2011 19:55:28 +0930 From: Mark Smith To: Doug Barton Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Message-ID: <20110525195528.673dccaf@opy.nosense.org> In-Reply-To: <4DDC32EF.3000507@dougbarton.us> References: <201105232010 .p4NKAV9X012654@cichlid.raleigh.ibm.com> <20110525064627.7f1f7746@opy.nosense.org> <4DDC32EF.3000507@dougbarton.us> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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: Thomas Narten , Bob Hinden , "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, 25 May 2011 10:25:44 -0000 Hi Doug, On Tue, 24 May 2011 15:36:31 -0700 Doug Barton wrote: > On 05/24/2011 15:00, Templin, Fred L wrote: > > Good point; yes, even DHCPv6 requires link-locals. The > > link-locals could be manually configured, but it seems > > reasonable to assume that they would often be autoconfigured > > using SLAAC. > > I'm confused (nothing new about that). In FreeBSD the OS creates the > LLA, which is then used for rtsol, etc. Are we doing it wrong? > No. I was more clarifying/observing that if link-locals are classified as SLAAC addresses, a pure non-SLAAC environment is impossible because of the required presence of link-locals for purposes such as those you mention. Regards, Mark. From tjc@ecs.soton.ac.uk Wed May 25 04:39:25 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 589B3E0716 for ; Wed, 25 May 2011 04:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 CWLJPTYDlEDs for ; Wed, 25 May 2011 04:39:24 -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 E593BE0715 for ; Wed, 25 May 2011 04:39:23 -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 p4PBdGj5012435 for ; Wed, 25 May 2011 12:39:16 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p4PBdGj5012435 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1306323556; bh=xM33XTxT+7vZqRNSLjTM4wOzKlM=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=O2qG8qAN001gG4APAUUAg3RPYTT/V1gAB4Lh+EPtVJe2N4TsSuB5OKDslThnLiTHu KAquXDJaMdjpN1Sd3BB4N41zKoy4w8qstJJS6mYlYwuZJLGXSL08N/hOU7QWkqg0vx FQ18yEkJDmbuxeVvl4upogExioaEGip78kN1SlIs= 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 n4OCdG0035632867w7 ret-id none; Wed, 25 May 2011 12:39:16 +0100 Received: from dhcp-152-78-94-92.ecs.soton.ac.uk (dhcp-152-78-94-92.ecs.soton.ac.uk [152.78.94.92]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p4PBd8ZI016543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 25 May 2011 12:39:08 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: Tim Chown In-Reply-To: Date: Wed, 25 May 2011 12:39:08 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20110524072631.737ee12c@opy.nosense.org> <4DDADBFD.7000803@gmail.com> <20110524080154.513002bf@opy.nosense.org> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n4OCdG003563286700; tid=n4OCdG0035632867w7; 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: p4PBdGj5012435 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: Wed, 25 May 2011 11:39:25 -0000 On 24 May 2011, at 00:48, Christopher Morrow wrote: > On Mon, May 23, 2011 at 7:07 PM, Manfredi, Albert E > wrote: >> Mark Smith wrote: >=20 >> Mark, as I suggested previously, DHCP is useful in cases where you = need the IP addresses of hosts in a network to be predictable. I have no = idea why cable systems want DHCP, but I'm saying that IN GENERAL, if = hosts needs to know a priori what the address of other hosts is, SLAAC = falls flat on its face. >>=20 >> For example, a peer-to-peer network, where you don't want to rely on = a DNS. >=20 > really, the simplest case is enterprise networks: > joe's machine always gets address 1:2:3::4/128 > janes machine always gets 1.2.3::5/128 >=20 > this way techsupport always has a predictable mapping for these hosts, > they can identify form log messages over time what jane vs joe did... > not have ot worry about keeping track of the vagaries of privacy > addressing and jane/joe/etc flip flopping around the subnet at > "random". Whether you can enforce that jane only uses 1:2:3::5 and doesn't also = use other self-selected addresses is another question; in IPv6 it's = easier for devices to use different or additional addresses without = causing address conflicts. Thus having the tools to monitor which = addresses are appearing where is pretty useful. > Brian's point though is fair: Drive through, nothing new to discuss > here (wrt WHY) On the matter of the subject line, yes :) Tim From rja.lists@gmail.com Wed May 25 07:41: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 13B54E06FD for ; Wed, 25 May 2011 07:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 nyhwpb56WQuh for ; Wed, 25 May 2011 07:41:07 -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 52712E0655 for ; Wed, 25 May 2011 07:41:07 -0700 (PDT) Received: by vws12 with SMTP id 12so7060149vws.31 for ; Wed, 25 May 2011 07:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=iBdGlA9Dj145n0VM+n6khiU4eCEA1d1EO25Xb/vo8mY=; b=p+e0k/YbhVaSOMNo+dLASr0re6+Kk0mtma5YkvuMp3KfQjpu0bqOB37p+78A9j2TmJ jxu5td3K0hgrTbmG1+zJTbdwymdqx12UGMzCxcjtwz+yVzQ0YsddUHb7zH4+qD16vSS8 V/nDRCP11he+r6dKdbrOMyXkwlwy6nF1DpXag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=NZq1/M20CsLdlmcuOSZL+bnYBLzevj3nY+fo0h42tntufkViEzj5fmPYgm31L/GCWD FmnOheRwahwGeEgw8+g5gaqEZ/ty57qjJpTFIfwB1hWcYPChigFQJqzNxCyrCyxFdFNi Q6LIQHYiiaFpE1W149rTvJorEO19B13Z0RpgY= Received: by 10.52.178.164 with SMTP id cz4mr3044031vdc.43.1306334466750; Wed, 25 May 2011 07:41:06 -0700 (PDT) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id z18sm4142697vbx.14.2011.05.25.07.41.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2011 07:41:05 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Date: Wed, 25 May 2011 10:41:03 -0400 Message-Id: <4697C7A2-8FE5-4A7B-A8B9-2830398232F0@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 25 May 2011 14:41:08 -0000 On Weds 25th May 2011, 09:17:40 +1200, Brian Carpenter wrote: > As far as the document currently under discussion is concerned, > surely we are done? Absolutely yes. And if some folks want to have a discussion about some topic other than what this document ought to say, it would be very pleasant if those folks would use a different Subject: line -- simply so that separate discussion threads are kept separate. Yours, Ran From bob.hinden@gmail.com Wed May 25 08:53: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 79C95E06B5 for ; Wed, 25 May 2011 08:53:20 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 ekuVZ4M7Ebmh for ; Wed, 25 May 2011 08:53:20 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1DDAE06AF for ; Wed, 25 May 2011 08:53:19 -0700 (PDT) Received: by pvh18 with SMTP id 18so4589727pvh.31 for ; Wed, 25 May 2011 08:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0MbMqn3krcXYONCWKr8+rYtYXTEz3lU/IfGNyRIN6uI=; b=eo9PaiFslzMc+AdUwjg+VtEr6gbeb3O1oU2/Kwmp//TEb3pzqhvOXPbIOKKxlilEm0 L8ADgc6QHS43CtSAcR9Qd+SPSV+uNNZDRJcTDx708lU+u30D3HcR+YCPz0yHHyRxCuKr 7cUD5S3w+NHvFQT31HpXFgd5NTs/QIaE5b6aE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=bfHZgh4NalDwaickZdP6mHoilgpI3et1L8mNSWwQbsXVbPKvfubOoFky7fM3cX5cLx iJ/U9fXITWM04rSGeEBOXEKp0sr5Ny6O6KmH0aIn2wQY0ThQFDNus4MC7YvJdb0MMlDv yvHvYE15XH2nrPOAqIZjBxogpuawqPcdTdP0M= Received: by 10.142.217.18 with SMTP id p18mr1326916wfg.248.1306338799592; Wed, 25 May 2011 08:53:19 -0700 (PDT) Received: from [10.0.0.37] (c-24-130-225-13.hsd1.ca.comcast.net [24.130.225.13]) by mx.google.com with ESMTPS id k7sm7752871wfa.2.2011.05.25.08.53.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2011 08:53:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Advancing From: Bob Hinden Date: Wed, 25 May 2011 08:53:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D97E0EF-0BB9-4A11-858A-9736E5B71EF2@gmail.com> References: <201105231618.p4NGI4sk010943@cichlid.raleigh.ibm.com> To: 6man Mailing List X-Mailer: Apple Mail (2.1084) Cc: Bob Hinden 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, 25 May 2011 15:53:20 -0000 6man w.g., The 6man chairs believe the working group has reached a consensus on = advancing this version of the update to Node Requirements to the IESG. = The current discussion on the list relating to SLAAC and DHCPv6 is out = of scope for the Node Requirements document. There is more involved in = the discussion than can be dealt with by changing requirements language = as would be appropriate for the Node Requirements document. =20 We plan to advance to the IESG = later today. Regards, Bob Hinden & Brian Haberman 6man Chairs Begin forwarded message: > From: Thomas Narten > Date: May 23, 2011 9:18:04 AM PDT > To: ipv6@ietf.org > Subject: Re: I-D Action: draft-ietf-6man-node-req-bis-10.txt >=20 > WG, >=20 > I believe this version is ready to advance to the IESG. >=20 > =46rom the changes section: >=20 >> 17.1. Appendix: Changes from -09 to -10 >>=20 >> 1. With changes in requirements for IPsec and Routing Headers, >> clarified language regarding processing of unknown options, and >> removed paragraph lising which extension headers were required = to >> be implemented. >=20 > Above changes are in Section 5.1. >=20 >> 2. Removed "RFC4292-bis" from title. >> 3. Expanded the text on Jumbograms. >> 4. Changed recommendation of DHCPv6 from MAY to SHOULD. >> 5. Expanded the text on RFC4191, and changed recommendation from = MAY >> to SHOULD. >=20 > The last 3 changes have recently been discussed on the mailing list. >=20 > Thomas >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nordmark@acm.org Wed May 25 08:59:59 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 CC74AE06A8 for ; Wed, 25 May 2011 08:59:59 -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=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 6+Iw-2YEpzXt for ; Wed, 25 May 2011 08:59:59 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 09B51E067C for ; Wed, 25 May 2011 08:59:59 -0700 (PDT) Received: from [10.0.1.6] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p4PFxr3p002286 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 25 May 2011 08:59:53 -0700 Message-ID: <4DDD2778.2030008@acm.org> Date: Wed, 25 May 2011 08:59:52 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ray Hunter Subject: Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt References: <4DDABDA6.2070705@globis.net> <4DDBE1BF.7040104@acm.org> <4DDBF9E9.1040702@globis.net> In-Reply-To: <4DDBF9E9.1040702@globis.net> 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: Wed, 25 May 2011 15:59:59 -0000 On 5/24/11 11:33 AM, Ray Hunter wrote: > Thanks very much for replying. > > I think that I understand the motivation in that multicast is expensive > on some media, and that you thus want to avoid it. > > I'm always prepared to be dazzled by my lack of knowledge or incorrect > assumptions. I'd much rather ask a dumb question and get a smart answer > than just say nothing. > > The idea of the draft seems to be that spending more time performing > unicast neighbor solicitations in the "probe" state might avoid deleting > the neighbor entry, and thus the relearning the entry via "expensive" > multicast NS from the "-" state. If the NCE is retained, there is the added benefit of knowing that a node with that IPv6 address exists (or recently existed) on the link, which is helpful to know when dealing with DoS scans across the IPv6 address space. > Seems perfectly reasonable and something worth pursuing. Good. > Erik Nordmark wrote: >> Are you assuming that the routers inject host routes into the routing >> system based on the ND state? The routers inject a route for the >> subnet prefix which isn't tied to the ND state in any way. > > Yes, on the local link the router injects RA information based on a > (statically configured or PD learned) prefix. But routers and other > devices also redistribute reachability information elsewhere via other > protocols. > > The assumption that ND really is independent of everything else is what > I'm questioning myself, although I freely admit to a large dose of hand > waving here. ND isn't like ARP, as you of course know. In terms of the interaction with routing, I certainly don't know of any case where RFC 4861 behaves differently than RFC 826. Perhaps you can enlighten me on the differences you see in the interaction with routing? > An ARP cache entry would sit there silently for 4 hours by default and > do nothing, so packets could black hole if the next hop was learned via > a static route. Higher level protocols would have to detect the problem > themselves. Such an ARP implementation wouldn't follow RFC 1122. Note that RFC 1122 also has a MUST for dead gateway detection (with "gateway" being an old term for "router"), but it doesn't specify how that is performed, and I don't think it is commonly implemented in hosts. NUD was designed to solve the dead gateway detection, but generalizing it to nodes instead of just routers. > ND removing an entry by NUD probe failure retriggers next hop > determination, and AFAIK also actively triggers replying to remote nodes > with an ICMP unreachable message, and so ND can thus can effectively > disseminate reachability information far further than just the local link. > > A later post I made gave an example of reachability info being > indirectly based on ND (via a BGP neighbor peering TCP session becoming > unreachable due to an ICMPv6 unreachable, leading to route information > changing). I can imagine the same for EIGRP, OSPF if their neighbors > disappear due to receipt of an ICMPv6 unreachable (although > traditionally these implementations have tended to ignore ICMP for good > reason). Again, if you look at RFC 1122 you'll find that (in section 4.2.3.9) "TCP MUST NOT abort the connection" for the soft errors like many ICMP unreachables. Such soft errors might be for transient conditions, and the intention is that TCP survive such transients. Thus I think your (hopefully hypothetical) example indicates bad TCP implementation. > Another example sort of device that sometimes transmist reachability > information via TCP are WAN accelerators, that auto build network > tunnels, and then send routing information across these. Again, an > ICMPv6 unreachable might cause the device to tear down the tunnel. Ditto. > HSRP preference metrics can also potentially be influenced by > reachability information (ND) from another link (via track commands). > > Then there are also those dreaded silent devices (that we don't talk > much about but which are generally plonked on the very most critical > link into the main data centre), such as network intrusion detection > systems and firewalls, that actively monitor traffic across their links, > but that don't take part in any official routing protocol exchanges, and > can fail over to a back up system without informing anyone else by > marking interfaces up and down. > > Using the example of spanning tree, waiting for STP would probably mean > waiting 35 seconds (max_age + forwarding delay) in the default case for > the root bridge to send out topology notification BPDU's. That's a long > time in many protocols. Sure. And a protocol like BGP might be tuned to timeout in less time than 35 seconds (whether or not that is a good timeout isn't my point). But that wouldn't be impacted whether IPv4 or IPv6 is used. I think there is good operational understanding of how to tune things for IPv4, and that shouldn't have to change as IPv6 gets more widely deployed. I don't see the ICMP address unreachable errors due to NUD failures making a difference, because TCP must not reset the connection as a result of them. But I do see the three second NUD hard limit as being a case where IPv6/ND is different than IPV4/ARP for no good reason. > So I guess the question is also, do you want NUD to inform higher layers > of the need for a fail over ASAP of a local link failure via ICMP > unreachables (as Thomas seemed to suggest), or do you want ND to shut up > and just keep on retrying locally and let those higher layer protocols > hit their own time outs and take their own fail over actions? There is a huge difference between making local decisions based on NUD failures (such as a host using a different default router) and trying to interpret the ICMP address unreachable from afar. My take is that the ICMP address unreachable is a useful diagnostic tool - ping and traceroute will report it - but it is a soft error hence it doesn't make sense to have TCP or other protocols give up as a result of such ICMP errors. > Current ND seems to go the ASAP route with its 3 second timeout. > Historically, ARP seems to go the silent route. > > It just feels to me like all nodes on a common link should behave the > same way in this respect (no scientific argument, just raw gut feeling > of deja vu, and impending packet storms) I don't understand why you think all the nodes on a link need to be coordinated in such a way; the Internet protocols are designed to be robust and not assume that all the nodes have the same code and tuning. For instance, we don't require that ARP or TCP on all the nodes on a link to have the same timer values, and things work just fine. Erik > And if all nodes on the link aren't behaving the same way, don't you > still get say 50% of the multicasts as the partner nodes revert to the > "-" state by timing out "too fast" for that link type? > > Just seems like another reason to have this as a "per link" parameter > rather than a "per node" parameter. > > Best regards, > RayH > From nordmark@acm.org Wed May 25 09:00: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 A1AC9E0750 for ; Wed, 25 May 2011 09:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.266 X-Spam-Level: X-Spam-Status: No, score=-104.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] 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 xnjjTjgjEOBa for ; Wed, 25 May 2011 09:00:55 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1D2E0726 for ; Wed, 25 May 2011 09:00:46 -0700 (PDT) Received: from [10.0.1.6] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p4PG0glU003142 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 25 May 2011 09:00:43 -0700 Message-ID: <4DDD27AA.30409@acm.org> Date: Wed, 25 May 2011 09:00:42 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Philip Homburg Subject: Re: Neighbor Unreachability Detection is too impatient 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: Wed, 25 May 2011 16:00:55 -0000 On 5/25/11 2:10 AM, Philip Homburg wrote: > In your letter dated Tue, 24 May 2011 10:22:09 -0700 you wrote: >> On 5/24/11 10:12 AM, Philip Homburg wrote: >> With current RFC 4861 this means that the NCE has to be discarded, since >> the neighbor is deemed UNREACHABLE. >> >> Without the NCE, the next time the node tries to send a packet, it will >> end up multicasting NS messages. > > So you are saying (with a bit exaggeration from my side) that some links > in data centers have so many hosts that a network disruption of a few seconds > will cause a multicast storm big enough to meltdown the network. Philip, No that isn't what I said. I said that the current assumed maximum 3 NUD probes one second apart makes IPv6/ND less flexible than IPv4/ARP, and I think we should remove those constraints. I'm having a hard time understanding what point you are trying to make, and whether or not it relates to the text in the draft. Please send some suggested text changes to the draft if you think that would address your concern. Thanks, Erik > With modern CPUs and a Gbit/s network that seems very odd to me. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From bob.hinden@gmail.com Wed May 25 09:03: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 A0C27E07C8; Wed, 25 May 2011 09:03:17 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 yDQBpIn0xCyy; Wed, 25 May 2011 09:03:17 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 75A8CE0718; Wed, 25 May 2011 09:03:16 -0700 (PDT) Received: by pwi5 with SMTP id 5so4653230pwi.31 for ; Wed, 25 May 2011 09:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version:x-mailer; bh=Rkx6DmjuvShm0R8QGnla20s27rXF9Nc46KxZ3NPCSig=; b=a8jI+xlzJCKxRYKiJJuJ4TjWvrtOknW2a17WOwUpIaBThSVtMS4CUja6XSeNyLP9qI Uo9eKqL7YI5V9OPP5MZ8gILCP7+4SH5ZirshM1yIBKPvTY43YI9+dC5oA2bap6OAIG8X PGoM9W0BLhbW1HK9xY0S7JohrF+z8nx32VhVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=BaFhpjYXWnCKW2Vz5XL0ZExEGvyUzZqL66m1AM+E7fNUTWuO8d3O+1Y5HLm/aiQx3W GMy26RI4uTwih4FZ26rfuhagoYd1JcU94Ul9DbxPNaqZXQPsxybNmldu0z3rKffoUMLz 38S283xkKTfjn8ntnB8YvheteIxbTAIugWEFE= Received: by 10.68.30.196 with SMTP id u4mr3439148pbh.27.1306339396091; Wed, 25 May 2011 09:03:16 -0700 (PDT) Received: from [10.0.0.37] (c-24-130-225-13.hsd1.ca.comcast.net [24.130.225.13]) by mx.google.com with ESMTPS id p17sm5753752pbt.83.2011.05.25.09.03.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2011 09:03:14 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Request To Advance: Date: Wed, 25 May 2011 09:03:12 -0700 Message-Id: <5D773656-B4EA-45ED-9B3E-F40A9DAE64B4@gmail.com> To: Jari Arkko , Ralph Droms Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: iesg-secretary@ietf.org, Brian Haberman , Bob Hinden , 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: Wed, 25 May 2011 16:03:17 -0000 Jari & Ralph, On behalf of the 6MAN WG, the chairs request the advancement of: Title : IPv6 Node Requirements Author(s) : Ed Jankiewicz, John Loughney, Thomas Narten Filename : draft-ietf-6man-node-req-bis-10.txt Pages : 31 Date : 2011-05-23 as an Informational RFC. A two week 6MAN working group Last Call = completed on January 6, 2011 and a second one week last call ended on = May 6, 2011. The current draft resolves issues raised during to these = last calls. The chairs believe there is a consensus in the w.g. to move = this document forward. Regards, Bob Hinden & Brian Haberman 6MAN chairs From pch-b2B3A6689@u-1.phicoh.com Wed May 25 09:09:30 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 7E602E0715 for ; Wed, 25 May 2011 09:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 t0H94hwTlL+f for ; Wed, 25 May 2011 09:09:30 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6D526E0690 for ; Wed, 25 May 2011 09:09:29 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QPGeF-0001jYC; Wed, 25 May 2011 18:09:27 +0200 Message-Id: To: Erik Nordmark Subject: Re: Neighbor Unreachability Detection is too impatient From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <4DDBDE7F.5070706@acm.org> <4DDBE941.8030007@acm.org> <4DDD1AB7.7030904@sonic.net> In-reply-to: Your message of "Wed, 25 May 2011 08:05:27 -0700 ." <4DDD1AB7.7030904@sonic.net> Date: Wed, 25 May 2011 18:09:27 +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: Wed, 25 May 2011 16:09:30 -0000 In your letter dated Wed, 25 May 2011 08:05:27 -0700 you wrote: >I said that the current assumed maximum 3 NUD probes one second apart >makes IPv6/ND less flexible than IPv4/ARP, and I think we should remove >those constraints. > >I'm having a hard time understanding what point you are trying to make, >and whether or not it relates to the text in the draft. Please send some >suggested text changes to the draft if you think that would address your >concern. In my opinion, the current spec is simple and it works well. The advantage of precisely defining all the protocol contants also means that you predict what nodes are going to do. With ARP you are never sure. One way to move forward is to define an option for router advertisements to change some of the constants you want changed. Another option is to just update the RFC with new constants. NUD a lot of stuff. It detects that a system is down, allowing higher levels to take an alternative path. It detects that a system got a new MAC address (something you can easily found out from ARP broadcasts, but not as easily from ND multicasts), it can expire routers that down, not just for default routers but also after a redirect, and for prefixes with the onlink bit clear, the same applies to hosts. So there is a lot of stuff going on there. You do really want to just randomly mess with that? >From reading your draft, you never seemed to have considered the case that a node would get a new ethernet address. So, I have two complaints. The problem statement is one of hand waving. Yes, there will be a few more multicasts. No numbers on how badly it fails. Second, I don't think it should be left to individual implementors. If you want to create an additional nob for administrators, then just do so. Or if 3 NUD packets is just too few, then propose increasing it. From nordmark@sonic.net Wed May 25 08:05: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 F0970E07D5 for ; Wed, 25 May 2011 08:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 OTXrL5mzFijk for ; Wed, 25 May 2011 08:05:32 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 45548E07E5 for ; Wed, 25 May 2011 08:05:30 -0700 (PDT) Received: from [10.0.1.6] (128-107-239-234.cisco.com [128.107.239.234]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p4PF5RHL014902 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 25 May 2011 08:05:29 -0700 Message-ID: <4DDD1AB7.7030904@sonic.net> Date: Wed, 25 May 2011 08:05:27 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Philip Homburg Subject: Re: Neighbor Unreachability Detection is too impatient References: <4DDBDE7F.5070706@acm.org> <4DDBE941.8030007@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 25 May 2011 09:23:06 -0700 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, 25 May 2011 15:05:33 -0000 On 5/25/11 2:10 AM, Philip Homburg wrote: > In your letter dated Tue, 24 May 2011 10:22:09 -0700 you wrote: >> On 5/24/11 10:12 AM, Philip Homburg wrote: >> With current RFC 4861 this means that the NCE has to be discarded, since >> the neighbor is deemed UNREACHABLE. >> >> Without the NCE, the next time the node tries to send a packet, it will >> end up multicasting NS messages. > > So you are saying (with a bit exaggeration from my side) that some links > in data centers have so many hosts that a network disruption of a few seconds > will cause a multicast storm big enough to meltdown the network. Philip, No that isn't what I said. I said that the current assumed maximum 3 NUD probes one second apart makes IPv6/ND less flexible than IPv4/ARP, and I think we should remove those constraints. I'm having a hard time understanding what point you are trying to make, and whether or not it relates to the text in the draft. Please send some suggested text changes to the draft if you think that would address your concern. Thanks, Erik > With modern CPUs and a Gbit/s network that seems very odd to me. > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From v6ops@globis.net Wed May 25 10:58:59 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 83298E06E0 for ; Wed, 25 May 2011 10:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 W9lcea3M9dMV for ; Wed, 25 May 2011 10:58:58 -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 95527E0684 for ; Wed, 25 May 2011 10:58:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id EDAD58700CD for ; Wed, 25 May 2011 19:58:50 +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 F5iSdohKJH8R for ; Wed, 25 May 2011 19:58:41 +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 482E687007F for ; Wed, 25 May 2011 19:58:41 +0200 (CEST) Message-ID: <4DDD4351.7090502@globis.net> Date: Wed, 25 May 2011 19:58:41 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt References: <4DDABDA6.2070705@globis.net> <4DDBE1BF.7040104@acm.org> <4DDBF9E9.1040702@globis.net> <4DDD2778.2030008@acm.org> <4DDD42B9.8060902@globis.net> In-Reply-To: <4DDD42B9.8060902@globis.net> Content-Type: multipart/alternative; boundary="------------090600030402050408030401" 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, 25 May 2011 17:58:59 -0000 This is a multi-part message in MIME format. --------------090600030402050408030401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks once again for replying I think the differences are indeed down to bad implementations rather than specification. Although it is acknowledged in RFC5461 section 4.1 as late as 2009 that there are non-compliant implementations in the field where TCP does react to soft errors. Some of the kit I work on is a lot older than that. Also my operational experience of ARP says that dead gateway protection is not widely supported, and black holing was more the norm than the exception. Erik Nordmark wrote: > I don't understand why you think all the nodes on a link need to be > coordinated in such a way; the Internet protocols are designed to be > robust and not assume that all the nodes have the same code and > tuning. For instance, we don't require that ARP or TCP on all the > nodes on a link to have the same timer values, and things work just fine. > > Erik >> And if all nodes on the link aren't behaving the same way, don't you >> still get say 50% of the multicasts as the partner nodes revert to the >> "-" state by timing out "too fast" for that link type? >> >> Just seems like another reason to have this as a "per link" parameter >> rather than a "per node" parameter. >> >> Best regards, >> RayH The last point was simply one from an operational perspective. Forgive me for being such a low level guy. [side track] One of my grumbles about IPv6 is that network managers just don't have the standard/generic tools to be able to tune the behavior of end nodes effectively. There are quite a lot of host behaviors that are set with local preferences and have default values, but which are not coordinated across implementations. e.g. dare I mention SLAAC v. DHCPv6. As a network admin that's just a nightmare to manage in an environment where there are multiple operating systems, guest end nodes, traveling users, new nodes, old implementations...... half of the implementations are performing in a way that isn't suitable for your network, but you might not have admin rights on that end node, and there's no way to provide the end node with a hint of correct behavior. Think of a network using "Bring Your Own Device" policy where you do not have any admin control e.g. no Active Directory. There's seems to be no (effective) way of network equipment being able to signal to end nodes what is appropriate behavior for your particular network, compared to the simple existing tools like DHCPv4 options + extensions we are already have today. I'm sure certain SLAAC evangelists will tell me it's no business of mine to try to manage this at all, and self-configuration is the future. But never mind. [/side track] I've just read the RFC covering the (very interesting) mesh under / route over mechanism used in 6LoWPAN http://tools.ietf.org/html/draft-ietf-6lowpan-nd-16 . Very cool stuff. Even there it was a requirement that all nodes taking part in the network behave the same way. > The applicability of this specification is limited to LoWPANs where all nodes on the subnet implement these optimizations in a homogeneous way. So if the point of this draft is really to limit multicast, then from an operational perspective don't you want ALL nodes on a link to avoid using multicast as much as possible? So if the point of this draft is really to avoid operational problems with STP thrashing, then from an operational perspective don't you want ALL nodes on a link to avoid timing out too fast as much as possible? And how do the end nodes know what is appropriate operational behavior on this particular link? Out of scope of the draft ........ ? If that's really true that the end nodes do not have to behave the same way then I do not understand why the Reachable Time and the Retransmit Timer are sent in an RA message. Put it the other way around way: I don't understand then why it was considered so important that all nodes used the same values for Reachable Time and Retransmit Timer (for NUD), if it now isn't considered important that they even use the same retry mechanism in the probe state, or for how long that state can last. That's all I'm saying. If you perform link-level coordination for one set of parameters used by NUD, why not this particular one? Also for debugging, it's just one more thing to look at on that sniffer trace when spending a weekend / evening debugging in a data centre (not my favorite hobby and something I try to avoid). So is a node not responding because it is using exponential NUD back off, or is it not responding because a ND message is being dropped due to spanning tree thrashing around, or is it not responding because the end node implementation is plain broken? Hope this helps clarify where I'm coming from. It's not in any way a criticism of your draft, just a potential pointer to how it could be "improved" from the perspective of someone operational. regards, RayH --------------090600030402050408030401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks once again for replying

I think the differences are indeed down to bad implementations rather than specification.

Although it is acknowledged in RFC5461 section 4.1 as late as 2009 that there are non-compliant implementations in the field where TCP does react to soft errors. Some of the kit I work on is a lot older than that.

Also my operational experience of ARP says that dead gateway protection is not widely supported, and black holing was more the norm than the exception.

Erik Nordmark wrote:
I don't understand why you think all the nodes on a link need to be coordinated in such a way; the Internet protocols are designed to be robust and not assume that all the nodes have the same code and tuning. For instance, we don't require that ARP or TCP on all the nodes on a link to have the same timer values, and things work just fine.

   Erik

And if all nodes on the link aren't behaving the same way, don't you
still get say 50% of the multicasts as the partner nodes revert to the
"-" state by timing out "too fast" for that link type?

Just seems like another reason to have this as a "per link" parameter
rather than a "per node" parameter.

Best regards,
RayH
The last point was simply one from an operational perspective. Forgive me for being such a low level guy.

[side track]
One of my grumbles about IPv6 is that network managers just don't have the standard/generic tools to be able to tune the behavior of end nodes effectively. There are quite a lot of host behaviors that are set with local preferences and have default values, but which are not coordinated across implementations. e.g. dare I mention SLAAC v. DHCPv6.

As a network admin that's just a nightmare to manage in an environment where there are multiple operating systems, guest end nodes, traveling users, new nodes, old implementations...... half of the implementations are performing in a way that isn't suitable for your network, but you might not have admin rights on that end node, and there's no way to provide the end node with a hint of correct behavior.

Think of a network using "Bring Your Own Device" policy where you do not have any admin control e.g. no Active Directory.

There's seems to be no (effective) way of network equipment being able to signal to end nodes what is appropriate behavior for your particular network, compared to the simple existing tools like DHCPv4 options + extensions we are already have today. I'm sure certain SLAAC evangelists will tell me it's no business of mine to try to manage this at all, and self-configuration is the future. But never mind.
[/side track]

I've just read the RFC covering the (very interesting) mesh under / route over mechanism used in 6LoWPAN http://tools.ietf.org/html/draft-ietf-6lowpan-nd-16 . Very cool stuff.

Even there it was a requirement that all nodes taking part in the network behave the same way.
> The applicability of this specification is limited to LoWPANs where all nodes on the subnet implement these optimizations in a homogeneous way.


So if the point of this draft is really to limit multicast, then from an operational perspective don't you want ALL nodes on a link to avoid using multicast as much as possible?

So if the point of this draft is really to avoid operational problems with STP thrashing, then from an operational perspective don't you want ALL nodes on a link to avoid timing out too fast as much as possible?

And how do the end nodes know what is appropriate operational behavior on this particular link? Out of scope of the draft ........ ?

If that's really true that the end nodes do not have to behave the same way then I do not understand why the Reachable Time and the Retransmit Timer are sent in an RA message.

Put it the other way around way: I don't understand then why it was considered so important that all nodes used the same values for Reachable Time and Retransmit Timer (for NUD), if it now isn't considered important that they even use the same retry mechanism in the probe state, or for how long that state can last.

That's all I'm saying. If you perform link-level coordination for one set of parameters used by NUD, why not this particular one?

Also for debugging, it's just one more thing to look at on that sniffer trace when spending a weekend / evening debugging in a data centre (not my favorite hobby and something I try to avoid). So is a node not responding because it is using exponential NUD back off, or is it not responding because a ND message is being dropped due to spanning tree thrashing around, or is it not responding because the end node implementation is plain broken?

Hope this helps clarify where I'm coming from. It's not in any way a criticism of your draft, just a potential pointer to how it could be "improved" from the perspective of someone operational.

regards,
RayH

--------------090600030402050408030401-- From jari.arkko@piuha.net Wed May 25 11:22: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 D7718130067 for ; Wed, 25 May 2011 11:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 fI1sbPAHBpdu for ; Wed, 25 May 2011 11:22:40 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 248C2130011 for ; Wed, 25 May 2011 11:22:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7C5752CC3B; Wed, 25 May 2011 21:22:38 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GfMd6KNGmKa; Wed, 25 May 2011 21:22:37 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 0C7A12CC2F; Wed, 25 May 2011 21:22:36 +0300 (EEST) Message-ID: <4DDD48EB.7060702@piuha.net> Date: Wed, 25 May 2011 21:22:35 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF IPv6 Mailing List , draft-ietf-node-req-bis@tools.ietf.org, Ralph Droms Subject: review of draft-ietf-node-req-bis Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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, 25 May 2011 18:22:41 -0000 I have reviewed this draft. In general, this version is well written, I agree with the recommendations, and I'd like to thank everyone for working on this much needed update. I think the document is ready to go to IETF Last Call -- some minor issues below that I think could be addressed even during the last call. However, since I was part of the original design team that worked RFC 4294, I have asked Ralph to formally handle this document. He has promised to do so. (Thanks!) My comments: > Consequently, IPv6 Jumbograms [RFC2675 ] remain optional at this time. Other sections use RFC 2119 keywords (MAY) to state this. Consider using that style here as well. > Static address may be supported as well. > "Static addresses may be ..." or "Configuration of static address(es) may be ..." might be a better formulation. > For general purpose devices, RFC 4429 is not > considered to be necessary at this time. Hmm. I'd argue that moving and sleeping/waking nodes is perhaps more the norm than exception today. At the very least, I'd again use the MAY keyword for this specification. The above sounds almost like recommending to not implement it. > Consequently, DNS configuration > information can now be learned either through DHCP or through RAs. > Hosts will need to decide which mechanism (or whether both) should be > implemented. > I would make a forward reference here and add: "Specific guidance regarding DNS server discovery is discussed in Section 7." This is because for that specific issue we do have something stronger to say than the above text . (And based on my own experience of running non-IPv4 networks that desperately need DNS discovery, somewhere in Section 7 I think you should require that routers with attached hosts actually support both (stateless) DHCP and RA-based DNS discovery.) Jari From narten@us.ibm.com Wed May 25 11:34: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 BEC2913007B for ; Wed, 25 May 2011 11:34:32 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Ue+vO2l378Yf for ; Wed, 25 May 2011 11:34:32 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by ietfa.amsl.com (Postfix) with ESMTP id 26A0A13003D for ; Wed, 25 May 2011 11:34:32 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4PISUIR011599 for ; Wed, 25 May 2011 12:28:30 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p4PIY0jX123206 for ; Wed, 25 May 2011 12:34:01 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4PCXo7w022599 for ; Wed, 25 May 2011 06:33:50 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-253-223.mts.ibm.com [9.65.253.223]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4PCXmCU022504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 May 2011 06:33:49 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4PIXlTa008615; Wed, 25 May 2011 14:33:47 -0400 Message-Id: <201105251833.p4PIXlTa008615@cichlid.raleigh.ibm.com> To: Jari Arkko Subject: Re: review of draft-ietf-node-req-bis In-reply-to: <4DDD48EB.7060702@piuha.net> References: <4DDD48EB.7060702@piuha.net> Comments: In-reply-to Jari Arkko message dated "Wed, 25 May 2011 21:22:35 +0300." Date: Wed, 25 May 2011 14:33:47 -0400 From: Thomas Narten Cc: draft-ietf-node-req-bis@tools.ietf.org, IETF IPv6 Mailing List , Ralph Droms 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, 25 May 2011 18:34:32 -0000 Hi Jari. Some quick thoughts. I'm OK with most of your comments (they are mostly editorial). I personally think the IETF has gotten too formal wanting the word MAY when it ends up being stilted English. But that said, the wording (english) could still be improved as you note. > > For general purpose devices, RFC 4429 is not > > considered to be necessary at this time. > Hmm. I'd argue that moving and sleeping/waking nodes is perhaps more the > norm than exception today. At the very least, I'd again use the MAY > keyword for this specification. The above sounds almost like > recommending to not implement it. Just how much time does 4429 shave of the restarting of a device? not much I think. Couple of seconds? In reality, devices that are sleeping/waking take more than that to restore their state ... Also, just who has implemented 4429? Do we actually have real experience with it? > (And based on my own experience of running non-IPv4 networks that > desperately need DNS discovery, somewhere in Section 7 I think you > should require that routers with attached hosts actually support both > (stateless) DHCP and RA-based DNS discovery.) The trouble with routers being required to implement stateless is that they don't need to. You can have one DHC server for an entire site, with relay agents relaying packets to it... Thomas From cabo@tzi.org Wed May 25 11:44:59 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 35A3713008C for ; Wed, 25 May 2011 11:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 8KAlPnVkMh5o for ; Wed, 25 May 2011 11:44:58 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5944E13003D for ; Wed, 25 May 2011 11:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p4PIiQS1025566; Wed, 25 May 2011 20:44:26 +0200 (CEST) Received: from [192.168.217.101] (p5489BF83.dip.t-dialin.net [84.137.191.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 431A456C; Wed, 25 May 2011 20:44:25 +0200 (CEST) Subject: Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4DDD4351.7090502@globis.net> Date: Wed, 25 May 2011 20:44:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DDABDA6.2070705@globis.net> <4DDBE1BF.7040104@acm.org> <4DDBF9E9.1040702@globis.net> <4DDD2778.2030008@acm.org> <4DDD42B9.8060902@globis.net> <4DDD4351.7090502@globis.net> To: Ray Hunter 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: Wed, 25 May 2011 18:44:59 -0000 On May 25, 2011, at 19:58, Ray Hunter wrote: > I've just read the RFC covering the (very interesting) mesh under / = route over mechanism used in 6LoWPAN = http://tools.ietf.org/html/draft-ietf-6lowpan-nd-16 . Very cool stuff. Thanks! > Even there it was a requirement that all nodes taking part in the = network behave the same way. > > The applicability of this specification is limited to LoWPANs where = all nodes on the subnet implement these optimizations in a homogeneous = way. The idea here is that this draft updates RFC 4944 (the IP-over-foo for = IEEE 802.15.4, usually referred to as 6LoWPAN) so that *all* nodes on a = 6LoWPAN MUST implement 6LoWPAN-ND as opposed to ND-classic. > So if the point of this draft is really to limit multicast, then from = an operational perspective don't you want ALL nodes on a link to avoid = using multicast as much as possible? Yes, that is one of the reasons why we didn't try to tackle the = theoretical possibility of interoperation between nodes implementing = 6LoWPAN-ND and other nodes implementing ND-classic on 6LoWPANs, because = even listening for multicast is very expensive for some nodes there. > So if the point of this draft is really to avoid operational problems = with STP thrashing, then from an operational perspective don't you want = ALL nodes on a link to avoid timing out too fast as much as possible? There is no STP in 6LoWPAN, so that isn't a consideration for this = draft. Again, 6LoWPAN-ND is currently defined for non-Ethernet networks that = are homogeneously 6LoWPAN-ND, i.e. 802.15.4 (and, most likely once their = IP-over-foo documents stabilize, similar constrained networks such as = BT-LE or DECT-ULE),=20 However if people want to go ahead and do the work of adapting = 6LoWPAN-ND (or some of its elements) to other networks, e.g., Ethernet/WiFi, then one would have to open that can of worms. Gruesse, Carsten From jari.arkko@piuha.net Wed May 25 11:47:10 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 B1A8B1300A6 for ; Wed, 25 May 2011 11:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5MvN8A-G30IZ for ; Wed, 25 May 2011 11:47:10 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id DB43F1300A1 for ; Wed, 25 May 2011 11:47:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E548B2CC3B; Wed, 25 May 2011 21:47:08 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17hrQS2E-IVm; Wed, 25 May 2011 21:47:05 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id CAB092CC2F; Wed, 25 May 2011 21:47:04 +0300 (EEST) Message-ID: <4DDD4EA8.8080405@piuha.net> Date: Wed, 25 May 2011 21:47:04 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Thomas Narten Subject: Re: review of draft-ietf-node-req-bis References: <4DDD48EB.7060702@piuha.net> <201105251833.p4PIXlTa008615@cichlid.raleigh.ibm.com> In-Reply-To: <201105251833.p4PIXlTa008615@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List , Ralph Droms 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, 25 May 2011 18:47:10 -0000 Thomas, >> Hmm. I'd argue that moving and sleeping/waking nodes is perhaps more the >> norm than exception today. At the very least, I'd again use the MAY >> keyword for this specification. The above sounds almost like >> recommending to not implement it. >> > > Just how much time does 4429 shave of the restarting of a device? not > much I think. Couple of seconds? In reality, devices that are > sleeping/waking take more than that to restore their state ... > Speak for your own devices :-) Seriously though, you are right of course that this may not be a big factor. That being said, button press - Internet is usable time is a significant usability factor in many devices. And on low-powered nodes the time spent having to wait before the device can go to sleep again can easily increase battery usage significantly. So I wouldn't rule out that its a significant issue in some cases. > Also, just who has implemented 4429? Do we actually have real > experience with it? > Not much if any experience -- agreed. I thought there was at least one implementation. But I guess we are having a philosophical discussion of what it takes to make a spec get a MAY in this document. I definitely agree that MUST or SHOULD is out of question. I think it would be fair to list the implementation and deployment experience in the draft, which you do for many specifications. This is the interesting information for the reader, and they can draw their own conclusions. But I also think that extensions in standards track RFCs deserve to be clearly marked as potential specifications to implement. >> (And based on my own experience of running non-IPv4 networks that >> desperately need DNS discovery, somewhere in Section 7 I think you >> should require that routers with attached hosts actually support both >> (stateless) DHCP and RA-based DNS discovery.) >> > > The trouble with routers being required to implement stateless is that > they don't need to. You can have one DHC server for an entire site, > with relay agents relaying packets to it... > Ok. Well, require a relay agent or a server then? Jari From ipng@69706e6720323030352d30312d31340a.nosense.org Wed May 25 13:27: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 16E861300C5 for ; Wed, 25 May 2011 13:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 4RKxRuaQPnq0 for ; Wed, 25 May 2011 13:27:40 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id C94941300A7 for ; Wed, 25 May 2011 13:27:39 -0700 (PDT) Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QPKg0-0007HA-HI; Thu, 26 May 2011 05:57:32 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 0277F3B338; Thu, 26 May 2011 05:57:32 +0930 (CST) Date: Thu, 26 May 2011 05:57:30 +0930 From: Mark Smith To: Jari Arkko Subject: Re: review of draft-ietf-node-req-bis Message-ID: <20110526055730.60e2d662@opy.nosense.org> In-Reply-To: <4DDD4EA8.8080405@piuha.net> References: <4DDD48EB.7060702@piuha.net> <201105251833.p4PIXlTa008615@cichlid.raleigh.ibm.com> <4DDD4EA8.8080405@piuha.net> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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: Thomas Narten , IETF IPv6 Mailing List , Ralph Droms 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, 25 May 2011 20:27:41 -0000 On Wed, 25 May 2011 21:47:04 +0300 Jari Arkko wrote: > Thomas, > > >> Hmm. I'd argue that moving and sleeping/waking nodes is perhaps more the > >> norm than exception today. At the very least, I'd again use the MAY > >> keyword for this specification. The above sounds almost like > >> recommending to not implement it. > >> > > > > Just how much time does 4429 shave of the restarting of a device? not > > much I think. Couple of seconds? In reality, devices that are > > sleeping/waking take more than that to restore their state ... > > > > Speak for your own devices :-) Seriously though, you are right of course > that this may not be a big factor. That being said, button press - > Internet is usable time is a significant usability factor in many > devices. And on low-powered nodes the time spent having to wait before > the device can go to sleep again can easily increase battery usage > significantly. So I wouldn't rule out that its a significant issue in > some cases. > > > Also, just who has implemented 4429? Do we actually have real > > experience with it? > > > > Not much if any experience -- agreed. I thought there was at least one > implementation. The Linux kernel has had an implementation since July 2007, although it is disabled by default. (2.6.22 release) A google search shows that apparently it was enabled by default for Opensuse recently to "to improve support for NFS over IPv6." http://gitorious.org/opensuse/kernel-source/commit/5e2ee40f92751c17694c51adaef00c35b00efe6f/diffs But I guess we are having a philosophical discussion of > what it takes to make a spec get a MAY in this document. I definitely > agree that MUST or SHOULD is out of question. I think it would be fair > to list the implementation and deployment experience in the draft, which > you do for many specifications. This is the interesting information for > the reader, and they can draw their own conclusions. But I also think > that extensions in standards track RFCs deserve to be clearly marked as > potential specifications to implement. > > >> (And based on my own experience of running non-IPv4 networks that > >> desperately need DNS discovery, somewhere in Section 7 I think you > >> should require that routers with attached hosts actually support both > >> (stateless) DHCP and RA-based DNS discovery.) > >> > > > > The trouble with routers being required to implement stateless is that > > they don't need to. You can have one DHC server for an entire site, > > with relay agents relaying packets to it... > > > > Ok. Well, require a relay agent or a server then? > > Jari > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From v6ops@globis.net Wed May 25 13:48:42 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 D75EF1300ED for ; Wed, 25 May 2011 13:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.738 X-Spam-Level: X-Spam-Status: No, score=-2.738 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 4d464bcsO2lq for ; Wed, 25 May 2011 13:48:42 -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 88C221300EB for ; Wed, 25 May 2011 13:48:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id A04668700AD; Wed, 25 May 2011 22:48:40 +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 5LYYgr37rt0S; Wed, 25 May 2011 22:48:34 +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 BD58E87007F; Wed, 25 May 2011 22:48:34 +0200 (CEST) Message-ID: <4DDD6B22.4030009@globis.net> Date: Wed, 25 May 2011 22:48:34 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Carsten Bormann Subject: Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt References: <4DDABDA6.2070705@globis.net> <4DDBE1BF.7040104@acm.org> <4DDBF9E9.1040702@globis.net> <4DDD2778.2030008@acm.org> <4DDD42B9.8060902@globis.net> <4DDD4351.7090502@globis.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010505010804010402010603" 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, 25 May 2011 20:48:42 -0000 This is a multi-part message in MIME format. --------------010505010804010402010603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Failed context switch on my part. I was trying to use draft-ietf-6lowpan-nd-16 as an example of modified ND being applied to all nodes on a certain link type for a specific operational reason. (Yes I understand draft-ietf-6lowpan-nd-16 is specifically targeted at only 6lowpan nodes, although of course your 6LBR will have to run both flavors of ND: one special type avoiding multicast on the 6lowpan interface, and the other on the "classic" interface) The comments I made about ALL nodes should modify their behavior were meant to be directed at draft-nordmark-6man-impatient-nud-00.txt. Apologies for any confusion on the use of "this draft" If you modify ND behavior for one node, from a purely operational perspective, it makes sense IMHO to make sure the modified ND behavior applies to all nodes on a particular link, so that you can obtain your desired operational result. /Grüße zurück aus Niederlande :-)/ RayH Carsten Bormann wrote: > On May 25, 2011, at 19:58, Ray Hunter wrote: > > >> I've just read the RFC covering the (very interesting) mesh under / route over mechanism used in 6LoWPAN http://tools.ietf.org/html/draft-ietf-6lowpan-nd-16 . Very cool stuff. >> > > Thanks! > > >> Even there it was a requirement that all nodes taking part in the network behave the same way. >> >>> The applicability of this specification is limited to LoWPANs where all nodes on the subnet implement these optimizations in a homogeneous way. >>> > > The idea here is that this draft updates RFC 4944 (the IP-over-foo for IEEE 802.15.4, usually referred to as 6LoWPAN) so that *all* nodes on a 6LoWPAN MUST implement 6LoWPAN-ND as opposed to ND-classic. > > >> So if the point of this draft is really to limit multicast, then from an operational perspective don't you want ALL nodes on a link to avoid using multicast as much as possible? >> > > Yes, that is one of the reasons why we didn't try to tackle the theoretical possibility of interoperation between nodes implementing 6LoWPAN-ND and other nodes implementing ND-classic on 6LoWPANs, because even listening for multicast is very expensive for some nodes there. > > >> So if the point of this draft is really to avoid operational problems with STP thrashing, then from an operational perspective don't you want ALL nodes on a link to avoid timing out too fast as much as possible? >> > > There is no STP in 6LoWPAN, so that isn't a consideration for this draft. > Again, 6LoWPAN-ND is currently defined for non-Ethernet networks that are homogeneously 6LoWPAN-ND, i.e. 802.15.4 (and, most likely once their IP-over-foo documents stabilize, similar constrained networks such as BT-LE or DECT-ULE), > However if people want to go ahead and do the work of adapting 6LoWPAN-ND (or some of its elements) to other networks, > e.g., Ethernet/WiFi, then one would have to open that can of worms. > > Gruesse, Carsten > > --------------010505010804010402010603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Failed context switch on my part.

I was trying to use draft-ietf-6lowpan-nd-16 as an example of modified ND being applied to all nodes on a certain link type for a specific operational reason. (Yes I understand draft-ietf-6lowpan-nd-16 is specifically targeted at only 6lowpan nodes, although of course your 6LBR will have to run both flavors of ND: one special type avoiding multicast on the 6lowpan interface, and the other on the "classic" interface)

The comments I made about ALL nodes should modify their behavior were meant to be directed at draft-nordmark-6man-impatient-nud-00.txt. Apologies for any confusion on the use of "this draft"

If you modify ND behavior for one node, from a purely operational perspective, it makes sense IMHO to make sure the modified ND behavior applies to all nodes on a particular link, so that you can obtain your desired operational result.

Grüße zurück aus Niederlande :-)
RayH

Carsten Bormann wrote: 
On May 25, 2011, at 19:58, Ray Hunter wrote:

  
I've just read the RFC covering the (very interesting) mesh under / route over mechanism used in 6LoWPAN http://tools.ietf.org/html/draft-ietf-6lowpan-nd-16 . Very cool stuff.
    

Thanks!

  
Even there it was a requirement that all nodes taking part in the network behave the same way.
    
The applicability of this specification is limited to LoWPANs where all nodes on the subnet implement these optimizations in a homogeneous way.
      

The idea here is that this draft updates RFC 4944 (the IP-over-foo for IEEE 802.15.4, usually referred to as 6LoWPAN) so that *all* nodes on a 6LoWPAN MUST implement 6LoWPAN-ND as opposed to ND-classic.

  
So if the point of this draft is really to limit multicast, then from an operational perspective don't you want ALL nodes on a link to avoid using multicast as much as possible?
    

Yes, that is one of the reasons why we didn't try to tackle the theoretical possibility of interoperation between nodes implementing 6LoWPAN-ND and other nodes implementing ND-classic on 6LoWPANs, because even listening for multicast is very expensive for some nodes there.

  
So if the point of this draft is really to avoid operational problems with STP thrashing, then from an operational perspective don't you want ALL nodes on a link to avoid timing out too fast as much as possible?
    

There is no STP in 6LoWPAN, so that isn't a consideration for this draft.
Again, 6LoWPAN-ND is currently defined for non-Ethernet networks that are homogeneously 6LoWPAN-ND, i.e. 802.15.4 (and, most likely once their IP-over-foo documents stabilize, similar constrained networks such as BT-LE or DECT-ULE), 
However if people want to go ahead and do the work of adapting 6LoWPAN-ND (or some of its elements) to other networks,
e.g., Ethernet/WiFi, then one would have to open that can of worms.

Gruesse, Carsten

--------------010505010804010402010603-- From narten@us.ibm.com Wed May 25 13:53: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 F2DA1E067F for ; Wed, 25 May 2011 13:53:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tG+RFMcm07KU for ; Wed, 25 May 2011 13:53:26 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 4F812E0658 for ; Wed, 25 May 2011 13:53:26 -0700 (PDT) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4PKgjm2016362 for ; Wed, 25 May 2011 16:42:45 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4PKrOQY124608 for ; Wed, 25 May 2011 16:53:24 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4PGrCle021568 for ; Wed, 25 May 2011 13:53:13 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-253-223.mts.ibm.com [9.65.253.223]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4PGrBhp021526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 May 2011 13:53:12 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4PKrMDp009478; Wed, 25 May 2011 16:53:22 -0400 Message-Id: <201105252053.p4PKrMDp009478@cichlid.raleigh.ibm.com> To: Erik Nordmark Subject: Re: Neighbor Unreachability Detection is too impatient In-reply-to: <4DDBE552.4070603@acm.org> References: <4DDAAB85.8000103@acm.org> <201105241245.p4OCjNpk006378@cichlid.raleigh.ibm.com> <4DDBE552.4070603@acm.org> Comments: In-reply-to Erik Nordmark message dated "Tue, 24 May 2011 10:05:22 -0700." Date: Wed, 25 May 2011 16:53:22 -0400 From: Thomas Narten 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, 25 May 2011 20:53:27 -0000 > Should I add your suggestion to the draft? Kind of depends on where you see your document going. Should we be looking at a more substantial effort to cleanup edge cases in ND? What issues are there and how big an effort will that turn into? Or should we be publishing small "stand alone" tweaks individually, consolidating them all at some point in the future? I suspect that some changes will come out of the ARMD WG effort. But it's a little early to know for sure yet what requirements might come out of that effort. Thomas From nordmark@acm.org Wed May 25 15:06: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 42B8FE073A for ; Wed, 25 May 2011 15:06:55 -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=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Y484XcBwoxJE for ; Wed, 25 May 2011 15:06:53 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id ED1DEE06AB for ; Wed, 25 May 2011 15:06:53 -0700 (PDT) Received: from [10.0.1.6] (128-107-239-234.cisco.com [128.107.239.234]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p4PM6oZr025482 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 25 May 2011 15:06:51 -0700 Message-ID: <4DDD7D7A.8060400@acm.org> Date: Wed, 25 May 2011 15:06:50 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Thomas Narten Subject: Re: Neighbor Unreachability Detection is too impatient References: <4DDAAB85.8000103@acm.org> <201105241245.p4OCjNpk006378@cichlid.raleigh.ibm.com> <4DDBE552.4070603@acm.org> <201105252053.p4PKrMDp009478@cichlid.raleigh.ibm.com> In-Reply-To: <201105252053.p4PKrMDp009478@cichlid.raleigh.ibm.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: Wed, 25 May 2011 22:06:55 -0000 On 5/25/11 1:53 PM, Thomas Narten wrote: >> Should I add your suggestion to the draft? > > Kind of depends on where you see your document going. > > Should we be looking at a more substantial effort to cleanup edge > cases in ND? What issues are there and how big an effort will that > turn into? Covering all possible edge cases is too open ended IMHO. But if we are going to clarify and relax things around retransmission behaviors in this draft, then we can attempt to address that whole area. Erik > Or should we be publishing small "stand alone" tweaks individually, > consolidating them all at some point in the future? > > I suspect that some changes will come out of the ARMD WG effort. But > it's a little early to know for sure yet what requirements might come > out of that effort. > > Thomas > From rja.lists@gmail.com Thu May 26 06:32:03 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 6B239E06DC for ; Thu, 26 May 2011 06:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 6LZDVOj+ZHEr for ; Thu, 26 May 2011 06:31:43 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7BEE06F3 for ; Thu, 26 May 2011 06:31:43 -0700 (PDT) Received: by qwc23 with SMTP id 23so519452qwc.31 for ; Thu, 26 May 2011 06:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=vvydG7MhJHuZAZl/Q8binYmxn3URlwL7B8yPB80d0Zs=; b=R+0sxLMZa54g3wJ+4XJCdojderQAuNk3CZgojVl/g71pQsGTxYmq+8W/S1GOu1sLvd qXgMTjdpFVhNlDwLslZZzB5I0rzA+v/8bV682Qk6BDJTKdzkpLJW+dl2YZWdl66clPZu kjgq/c8OazlhjfBPxIikg+k0y5mdoPcrJZnpY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=ky9tFbduJWfXSxSjbTjE56P+CqokFsqho7DjBUgOVIENexpQ7iFEhvqvSTJKYvTL98 hAKT+kk5euTri6vudhZxzTmn5WaHSBQqPJ0JCI93uN7jRD7JhNdgpXvnR2M57kfqOdxt +s9Zgcsu1wCRyj7pDb/LwM5IH/uQE45DXdDJs= Received: by 10.224.137.133 with SMTP id w5mr573525qat.178.1306416702628; Thu, 26 May 2011 06:31:42 -0700 (PDT) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id 12sm443840qcb.10.2011.05.26.06.31.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2011 06:31:41 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: review of draft-ietf-node-req-bis Date: Thu, 26 May 2011 09:31:40 -0400 Message-Id: <1A95B2DF-B4EE-4237-8855-05AEF7957803@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 26 May 2011 13:32:03 -0000 On 25th May 2011, at 14:33:47 -0400, Thomas Narten wrote in part: > I personally think the IETF has gotten too formal wanting > the word MAY when it ends up being stilted English. I agree with the above -- and I believe that this is a pretty widespread perspective among IETF participants. RFC-2119 is helpful, but some folks take an overly strict line that those are the only phrasings that one can use and often it impedes readability for discussions or topics that either aren't normative or don't need to be expressed in formal language (e.g. an aside that some item is optional). > % For general purpose devices, RFC 4429 is not > % considered to be necessary at this time. > > Earlier, on 25th May 2011, at 21:22:35 +05:00, Jari Arkko wrote in part: > > Hmm. I'd argue that moving and sleeping/waking nodes is perhaps more > > the norm than exception today. At the very least, I'd again use the > > MAY keyword for this specification. The above sounds almost like > > recommending to not implement it. > > Just how much time does 4429 shave of the restarting of a device? not > much I think. Couple of seconds? In reality, devices that are > sleeping/waking take more than that to restore their state ... > > Also, just who has implemented 4429? > Do we actually have real experience with it? All good questions. I agree that there is not sufficient operational experience with RFC-4429 to justify changing the text in this draft. If at some future point sufficient operational experience is demonstrated, then that experience might justify a change. However, we ought not hold up this draft while waiting for that experience to magically appear. > > (And based on my own experience of running non-IPv4 networks > > that desperately need DNS discovery, somewhere in Section 7 > > I think you should require that routers with attached hosts > > actually support both (stateless) DHCP and RA-based DNS discovery.) > > The trouble with routers being required to implement stateless > is that they don't need to. You can have one DHC server for an > entire site, with relay agents relaying packets to it... (I'm not sure what precisely was meant by "non-IPv4" above, perhaps that meant to read "non-IPv6" or perhaps it meant IPX ?) Anyway, I am personally very sympathetic to the observation that DNS Discovery is operationally important. My operational experience (from back when I led an access engineering group at a multi-continent broadband residential ISP) was that nearly all of our customers were unable to distinguish between "link down", "network down", and "DNS server misconfigured or down". In all 3 scenarios, they'd call Customer Service to open a trouble ticket and would tell the CSR "Internet is completely down". That said, Thomas has done a careful job of walking the tightrope between differing views within the WG about what ought or ought not be mandated in this draft. I suspect that changing the existing text in this area, as Jari proposes, might well decrease the consensus within the IPv6 WG. So I can't see making that change in this document at this time, despite my personal sympathy for the idea. Instead, perhaps there is a compelling case that it would be useful to have a separate informational document that describes the practical operational issues with DNS Discovery, including user perspective, operator perspective, and security perspective (e.g. authorisation to advertise DNS services, authentication of that advertisement). (One imagines such a draft might belong in the IPv6 Ops WG, as it would be about operational issues. :-) Yours, Ran From bob.hinden@gmail.com Thu May 26 09:24:12 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 801FDE0657 for ; Thu, 26 May 2011 09:24:12 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 7YwNzmF0prh2 for ; Thu, 26 May 2011 09:24:12 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id C11FDE0618 for ; Thu, 26 May 2011 09:24:09 -0700 (PDT) Received: by pvh18 with SMTP id 18so420586pvh.31 for ; Thu, 26 May 2011 09:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=MsDueUQZT8Jfo/4LEaoesmXrpP1oWf9lMM/xmrZi1oA=; b=VyQui2OezfAbYlOQq/nrXugyjGzmjpASm1Qu76M80Pdh4S3YaITiyWvYzsiAVHPpjx P/ndIi5kz5cDodzkz+dCgYUdesysVI8KXp2cglyjlkha3NPigI0UYJrJFQj27rx8PGh6 hJPIW4W/VN9xLdTT+2V3leAwgD9OGpwboSTD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=unvB+Ar5ubxp4YFbe/s4FKV0GuVoyfTEi8CbpgATcnJnKkNpH5vVASXTH1CXz0BIXP zney6mYTtBjwXwuJAbar/K2MhzdKKEk6RplZ7YTuU4jReCz5lLgo6jLMFlrr9oqQDDZy n3C0fLzgIlHqoJ7DRmCkTQES9YBW4VFASBSrA= Received: by 10.143.40.4 with SMTP id s4mr165508wfj.53.1306427049432; Thu, 26 May 2011 09:24:09 -0700 (PDT) Received: from [10.0.0.37] (c-24-130-225-13.hsd1.ca.comcast.net [24.130.225.13]) by mx.google.com with ESMTPS id a14sm769181wff.20.2011.05.26.09.24.06 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2011 09:24:08 -0700 (PDT) Subject: Re: review of draft-ietf-node-req-bis Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <1A95B2DF-B4EE-4237-8855-05AEF7957803@gmail.com> Date: Thu, 26 May 2011 09:24:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A514EDB-F414-4C4B-B093-A7DF23F961DD@gmail.com> References: <1A95B2DF-B4EE-4237-8855-05AEF7957803@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org, Bob Hinden 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, 26 May 2011 16:24:12 -0000 Ran, >=20 > I agree that there is not sufficient operational experience > with RFC-4429 to justify changing the text in this draft. >=20 > If at some future point sufficient operational experience=20 > is demonstrated, then that experience might justify a change. > However, we ought not hold up this draft while waiting for=20 > that experience to magically appear. I don't have a strong opinion on the specifics of RFC-4429, but I want = to point out the having sufficient operational experience isn't the only = criteria for including something in node requirements. It can be = something we think everyone should implement. For example, the recent consensus to change DHCPv6 to a SHOULD, was more = about making sure that all hosts implement it given current deployment = models. Bob From rja.lists@gmail.com Thu May 26 12:36:38 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 6445AE0717 for ; Thu, 26 May 2011 12:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 wLHS5EMq2Ozu for ; Thu, 26 May 2011 12:36:37 -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 9ABACE06E9 for ; Thu, 26 May 2011 12:36:37 -0700 (PDT) Received: by qyk7 with SMTP id 7so654005qyk.10 for ; Thu, 26 May 2011 12:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=N5oIM7OKlRfmacG9/IXW844OVqLHFuPEdTMxhcMdD7s=; b=bXs0/vVAv3aFoxvExfFzZLOBX56P23D4BwSqy+cVtTslZQ+1fbVpxo+WbIcqaZoiHM IqFD0fBChr5vvZcNdJEtJpqycISZJAM6x+tnH/GsKHvRztgXsvXEsTBUddj2axK5ZH1z zwVUVrGCjMOqkToIvPQgW35Ktp16tD6QuCMAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=jNKD3IWrwTb1WLV8dhdi4i7NiWxkg+sXA68dChH6q7upuUwXXMLVKEm14vlYz/HA7S Jm4Eagw6B2HY8EFQru+LN/A+SUrEstd45zFAeyx+Cu6XkUkFRMUqmrD/4SYbe84kgzyS RcpilTaF9iCq0Oo5Bn1i+P/x/KFbfTdVCshRo= Received: by 10.229.126.195 with SMTP id d3mr965738qcs.61.1306438596975; Thu, 26 May 2011 12:36:36 -0700 (PDT) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id f16sm623950qck.33.2011.05.26.12.36.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2011 12:36:36 -0700 (PDT) Subject: Re: review of draft-ietf-node-req-bis Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: RJ Atkinson In-Reply-To: <7A514EDB-F414-4C4B-B093-A7DF23F961DD@gmail.com> Date: Thu, 26 May 2011 15:36:34 -0400 Content-Transfer-Encoding: 7bit Message-Id: <1D026ED7-165F-4FC1-9707-8C5A10D9AE5E@gmail.com> References: <1A95B2DF-B4EE-4237-8855-05AEF7957803@gmail.com> <7A514EDB-F414-4C4B-B093-A7DF23F961DD@gmail.com> To: Bob Hinden 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: Thu, 26 May 2011 19:36:38 -0000 On 26 May 2011, at 12:24 , Bob Hinden wrote: > I don't have a strong opinion on the specifics of RFC-4429, > but I want to point out the having sufficient operational > experience isn't the only criteria for including something > in node requirements. I never said it was the ONLY criterion. It is a VALID criterion to consider. In contrast with RFC-4429, there is significant operational experience with DHCPv6 (e.g. in some enterprise environments). So drawing an analogue with DHCPv6 does not work for RFC-4429. All IMHO, Ran From narten@us.ibm.com Thu May 26 13:22: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 086F0E0779 for ; Thu, 26 May 2011 13:22:09 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNjfnzp5w-Jm for ; Thu, 26 May 2011 13:22:05 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by ietfa.amsl.com (Postfix) with ESMTP id E1572E0694 for ; Thu, 26 May 2011 13:22:04 -0700 (PDT) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e1.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4QKAgxi015237 for ; Thu, 26 May 2011 16:10:42 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4QKM25t561194 for ; Thu, 26 May 2011 16:22:02 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4QKM2Yc028398 for ; Thu, 26 May 2011 17:22:02 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-76-156-157.mts.ibm.com [9.76.156.157]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4QKM0WC028044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 May 2011 17:22:01 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4QKLx2b020404 for ; Thu, 26 May 2011 16:21:59 -0400 Message-Id: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com> To: ipv6@ietf.org Subject: Re: review of draft-ietf-node-req-bis Date: Thu, 26 May 2011 16:21:59 -0400 From: Thomas Narten 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, 26 May 2011 20:22:09 -0000 Going back to this... Jari Arkko writes: > I have reviewed this draft. In general, this version is well written, > I agree with the recommendations, and I'd like to thank everyone for > working on this much needed update. I think the document is ready to > go to IETF Last Call -- some minor issues below that I think could be > addressed even during the last call. > However, since I was part of the original design team that worked RFC > 4294, I have asked Ralph to formally handle this document. He has > promised to do so. (Thanks!) > > My comments: > > > Consequently, IPv6 Jumbograms [RFC2675 > ] remain optional at this > time. > > Other sections use RFC 2119 keywords (MAY) to state this. Consider > using that style here as well. I'd rather not make this change. I think MAY sounds stilted. In addtion, the defintion of MAY is "optional": 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) > Static address may be supported as well. > > "Static addresses may be ..." or "Configuration of static address(es) > may be ..." might be a better formulation. Agreed. > For general purpose devices, RFC 4429 is not considered to be > necessary at this time. > > Hmm. I'd argue that moving and sleeping/waking nodes is perhaps more > the norm than exception today. At the very least, I'd again use the > MAY keyword for this specification. The above sounds almost like > recommending to not implement it. Changed last sentence to: For general purpose devices, RFC 4429 remains optional at this time. > Consequently, DNS configuration > information can now be learned either through DHCP or through RAs. > Hosts will need to decide which mechanism (or whether both) should be > implemented. > > I would make a forward reference here and add: "Specific guidance > regarding DNS server discovery is discussed in Section 7." This is > because for that specific issue we do have something stronger to say > than the above text . Done. > (And based on my own experience of running non-IPv4 networks that > desperately need DNS discovery, somewhere in Section 7 I think you > should require that routers with attached hosts actually support both > (stateless) DHCP and RA-based DNS discovery.) New text: 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 Because a single DHCP server can support devices on multiple links, it is not necessary that every router support DHCPv6 directly. However, in order to support DHCPv6 servers on other links, routers SHOULD support relay agent functionality of DHCPv6 [RFC3315]. Routers MAY support full [RFC3315] or stateless [RFC4862] DHCPv6 server functionality as well. I'm on the fence wrt MAY/SHOULD on the recommendation above. I don't think every router needs to support DHCP, hence the MAY. But SHOULD is also not a MUST, so I'd be OK with SHOULD. Indeed, where one arguably should have a MUST is in relay agent functionality. SHould I elevate it? Thoughts? Thomas From bob.hinden@gmail.com Thu May 26 14:06:01 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 B09B6E06E1 for ; Thu, 26 May 2011 14:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.537 X-Spam-Level: X-Spam-Status: No, score=-103.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 n7C2lDLdhgZs for ; Thu, 26 May 2011 14:06:01 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 19D9FE06BA for ; Thu, 26 May 2011 14:06:01 -0700 (PDT) Received: by pvh18 with SMTP id 18so537106pvh.31 for ; Thu, 26 May 2011 14:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=+Rr6BqvthsMBbU2RqapSRFGb+aFcyBD8/GwAPuZXU5w=; b=tDHdbMvw0dJkrpD+cNZ8PZ+g4mDJoHH909cTsTQWDyL2mRiPKsRZkFjfYmZ2jMIpuf RhfCAXzwp9tYVZq7u9lAjfWJsUWBVSVleFf9Lmy7bL2cvn4p2TU8MGQgBvzbslZnFZ4Q XcRxofX9/HWh0N751JtaOfR/aegi0MTZeZQQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=eDm/agdUY9eMMtDd9sdD2/fk9w43TuOFtre6mSMIM95zYJKhpOVvt2AZSrv4UD1gGY thr4tSwj+Fg4c5IzOAD8GwBH0cSv5oYLCL2Yr/D0pia540IvzpjwfQa6PIJxxZk7LAyN do/K798sdBxr0oWp09cyF0l+UtCFC0TP9xx3A= Received: by 10.68.44.130 with SMTP id e2mr541208pbm.515.1306443960709; Thu, 26 May 2011 14:06:00 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id m9sm1692572pbd.9.2011.05.26.14.05.58 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2011 14:05:59 -0700 (PDT) Subject: Re: review of draft-ietf-node-req-bis Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com> Date: Thu, 26 May 2011 14:05:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org, Bob Hinden 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, 26 May 2011 21:06:01 -0000 Thomas, > New text: >=20 > 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 >=20 > Because a single DHCP server can support devices on multiple links, > it is not necessary that every router support DHCPv6 directly. > However, in order to support DHCPv6 servers on other links, routers > SHOULD support relay agent functionality of DHCPv6 [RFC3315]. > Routers MAY support full [RFC3315] or stateless [RFC4862] DHCPv6 > server functionality as well. >=20 > I'm on the fence wrt MAY/SHOULD on the recommendation above. I don't > think every router needs to support DHCP, hence the MAY. But SHOULD is > also not a MUST, so I'd be OK with SHOULD. >=20 > Indeed, where one arguably should have a MUST is in relay agent > functionality. SHould I elevate it? >=20 > Thoughts? >=20 I think SHOULD is more appropriate. There are going to be environments = where it's not needed. =20 Bob From ipng@69706e6720323030352d30312d31340a.nosense.org Thu May 26 14:26: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 21FFAE0755 for ; Thu, 26 May 2011 14:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 PCgIZzXMktMl for ; Thu, 26 May 2011 14:26:34 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id 31364E0694 for ; Thu, 26 May 2011 14:26:34 -0700 (PDT) Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QPi4b-0001jx-5M; Fri, 27 May 2011 06:56:29 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 5B1973B338; Fri, 27 May 2011 06:56:28 +0930 (CST) Date: Fri, 27 May 2011 06:56:26 +0930 From: Mark Smith To: Thomas Narten Subject: Re: review of draft-ietf-node-req-bis Message-ID: <20110527065626.48a97f41@opy.nosense.org> In-Reply-To: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com> References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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: Thu, 26 May 2011 21:26:35 -0000 Hi Thomas, On Thu, 26 May 2011 16:21:59 -0400 Thomas Narten wrote: > Going back to this... > > Jari Arkko writes: > > > New text: > > 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 > > Because a single DHCP server can support devices on multiple links, > it is not necessary that every router support DHCPv6 directly. > However, in order to support DHCPv6 servers on other links, routers > SHOULD support relay agent functionality of DHCPv6 [RFC3315]. > Routers MAY support full [RFC3315] or stateless [RFC4862] DHCPv6 > server functionality as well. > > I'm on the fence wrt MAY/SHOULD on the recommendation above. I don't > think every router needs to support DHCP, hence the MAY. But SHOULD is > also not a MUST, so I'd be OK with SHOULD. > > Indeed, where one arguably should have a MUST is in relay agent > functionality. SHould I elevate it? > > Thoughts? > I think relay should be a MUST. I want to see IPv6 achieve the same level of autoconfiguration that previous protocols like Appletalk and IPX achieved, which includes automated application/service parameter configuration. If the application/service parameter source is off link (i.e. an off-link DHCPv6 server), then currently the only way for those options to passed opaquely to end-nodes via a router is via a DHCPv6 relay capability. I've recently realised "route constraint" is currently a problem in an SP environment. As an SP, you want to automate as much as possible the configuration of all the services you provide to customers, such as providing DNS, SIP, NTP etc. parameters. If you add another service, and therefore add another DHCPv6 option to be provided to end-nodes, you need to have that new option get to the end-nodes for those that are interested in it, meaning that new option needs to "traverse" the CPE. However, currently the CPE RFC only says that the LAN interface should implement a DHCPv6 server, and provide options to the end-nodes using the options that the CPE has leaned via the DHCPv6-PD transaction on the WAN interface. This means that if the CPE doesn't support the new DHCPv6 option for the new service you've deployed, then the end-nodes can't be provided with that DHCPv6 option despite them supporting it. In a market where customers own and operate the CPE, the only DHCPv6 options a SP can therefore rely on being supported in CPE is likely to be no more than DNS addresses. For markets where the CPE is owned and operated by the SP, it still means a firmware update, supporting the new DHCPv6 option, has to be deployed to all CPE before the application can be deployed. In other words, a device in the network now constrains the deployment of a new application on the end-nodes. I think that situation is actually violating one of the most valuable principles of the Internet - that new application deployment doesn't have a dependency on the deployment of new capabilities in the network. So I think a DHCPv6 relay in routers should be a MUST. Somewhat off topic but related, I'm also thinking there should be a DHCPv6 option to convey one or more DHCPv6 server addresses that is learned by CPE during the DHCPv6-PD transaction, with the DHCPv6 server then used for a DHCPv6 relay operating on the LAN interface. An SP can then have the CPE LAN interface DHCPv6 relays pointing to a nominated off-link DHCPv6 server (the default without this new option could be the DHCPv6(-PD) server), which would allow CPE unsupported DHCPv6 options to transparently traverse the CPE, directly reaching the end-nodes. Regards, Mark. From narten@us.ibm.com Thu May 26 14:30: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 A225DE0745 for ; Thu, 26 May 2011 14:30:22 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6KDG+Rx1L0J for ; Thu, 26 May 2011 14:30:21 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by ietfa.amsl.com (Postfix) with ESMTP id 87038E06E1 for ; Thu, 26 May 2011 14:30:21 -0700 (PDT) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4QL9ABj013258 for ; Thu, 26 May 2011 17:09:10 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4QLUCX61200364 for ; Thu, 26 May 2011 17:30:12 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4QLUCmS029918 for ; Thu, 26 May 2011 17:30:12 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-76-156-157.mts.ibm.com [9.76.156.157]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4QLUBRW029826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 May 2011 17:30:12 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4QLUAQY020878; Thu, 26 May 2011 17:30:11 -0400 Message-Id: <201105262130.p4QLUAQY020878@cichlid.raleigh.ibm.com> To: Mark Smith Subject: Re: review of draft-ietf-node-req-bis In-reply-to: <20110527065626.48a97f41@opy.nosense.org> References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com> <20110527065626.48a97f41@opy.nosense.org> Comments: In-reply-to Mark Smith message dated "Fri, 27 May 2011 06:56:26 +0930." Date: Thu, 26 May 2011 17:30:10 -0400 From: Thomas Narten 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, 26 May 2011 21:30:22 -0000 Mark Smith writes: > I think relay should be a MUST. Let me ask a question. In IPv4, for typical SOHO routers, do they support DHCP relay agent functionality? (My guess is no.) And what about configuring it? It is *not* plug and play, zeroconf magic... Thomas From albert.e.manfredi@boeing.com Thu May 26 14:46:12 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 3D592E076D for ; Thu, 26 May 2011 14:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 AWy65JDaMSut for ; Thu, 26 May 2011 14:46:11 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 86898E0759 for ; Thu, 26 May 2011 14:46:11 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4QLk7ab006514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 May 2011 14:46:08 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p4QLk7EN028042; Thu, 26 May 2011 16:46:07 -0500 (CDT) Received: from XCH-MWHT-02.mw.nos.boeing.com (xch-mwht-02.mw.nos.boeing.com [134.57.113.20]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4QLk7jD028039 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 26 May 2011 16:46:07 -0500 (CDT) Received: from XCH-MWPFX-01.mw.nos.boeing.com (132.173.24.10) by XCH-MWHT-02.mw.nos.boeing.com (134.57.113.20) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 26 May 2011 16:46:06 -0500 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWPFX-01.mw.nos.boeing.com ([132.173.24.10]) with mapi; Thu, 26 May 2011 16:46:05 -0500 From: "Manfredi, Albert E" To: Thomas Narten Date: Thu, 26 May 2011 16:46:02 -0500 Subject: RE: review of draft-ietf-node-req-bis Thread-Topic: review of draft-ietf-node-req-bis Thread-Index: Acwb7DDeN5N4QTCzTG6nIUWByP9QWQAAGFfw Message-ID: References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com><20110527065626.48a97f41@opy.nosense.org> <201105262130.p4QLUAQY020878@cichlid.raleigh.ibm.com> In-Reply-To: <201105262130.p4QLUAQY020878@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.500.1024-18162.001 x-tm-as-result: No--45.371000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 26 May 2011 21:46:12 -0000 Thomas Narten wrote: > Let me ask a question. In IPv4, for typical SOHO routers, do they > support DHCP relay agent functionality? (My guess is no.) >=20 > And what about configuring it? It is *not* plug and play, zeroconf > magic... Since they are typically NAPTs, I'd say no. They are local DHCP servers for= the private address space behind them only. In IPv6, what will the "typical SOHO router" look like, though? Same NAT fu= nctionality as IPv4? And if not, is there an automatic way of configuring t= his SOHO router for any possible DHCP relay function? I agree with Thomas that a MUST involves consequences that need to be addre= ssed first. Bert From ipng@69706e6720323030352d30312d31340a.nosense.org Thu May 26 15:03:30 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 E0E6213002A for ; Thu, 26 May 2011 15:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 XE2n1eJcrl5G for ; Thu, 26 May 2011 15:03:30 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id C123D13003A for ; Thu, 26 May 2011 15:03:29 -0700 (PDT) Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QPieO-0002qR-Ax; Fri, 27 May 2011 07:33:28 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id EE5003B338; Fri, 27 May 2011 07:33:27 +0930 (CST) Date: Fri, 27 May 2011 07:33:27 +0930 From: Mark Smith To: Thomas Narten Subject: Re: review of draft-ietf-node-req-bis Message-ID: <20110527073327.2c5fee14@opy.nosense.org> In-Reply-To: <201105262130.p4QLUAQY020878@cichlid.raleigh.ibm.com> References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com> <20110527065626.48a97f41@opy.nosense.org> <201105262130.p4QLUAQY020878@cichlid.raleigh.ibm.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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: Thu, 26 May 2011 22:03:31 -0000 Hi Thomas, On Thu, 26 May 2011 17:30:10 -0400 Thomas Narten wrote: > Mark Smith writes: > > > I think relay should be a MUST. > > Let me ask a question. In IPv4, for typical SOHO routers, do they > support DHCP relay agent functionality? (My guess is no.) > I don't think they do, but I'm not sure why it matters. Aren't we talking about minimum IPv6 functionality that can be relied on being present? What has been deployed in IPv4 can be a guide (as can the past deployment of Appletalk and IPX where IPv6 has similar capabilities), but I don't think IPv4 deployment should be an overarching constraint on what can be done and is available under IPv6. > And what about configuring it? It is *not* plug and play, zeroconf > magic... > Exactly. That's the problem. If you know you can't or aren't very likely to be able to relay DHCP options to customer's end-nodes, you don't bother sending them. The myriad of DHCP(v4 and v6) options that exist that may be useful to an SP are currently of no or very little use because they can't be conveyed directly to customer's end-nodes across the CPE boundary. If an SP can convey DHCPv6 options "past the CPE" to the end-nodes, then IPv6 operation in the customers home can much more user friendly than IPv4's has been. And it needs to be. We've been able to get away with asking customers to type in IPv4 addresses, we won't get away with asking them to type in IPv6 addresses, and we shouldn't be asking them to manually type in DNS names when automated methods of providing them already exist. We just need to make them usable. SOHO CPE are the most common routers deployed, so I think any IPv6 router requirements minimums should be primarily guided by their functional requirements. Regards, Mark. From dougb@dougbarton.us Thu May 26 15:47:10 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 43CE9130029 for ; Thu, 26 May 2011 15:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.807 X-Spam-Level: X-Spam-Status: No, score=-3.807 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 trSzL8HHWNzS for ; Thu, 26 May 2011 15:47:09 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1F37C130026 for ; Thu, 26 May 2011 15:47:09 -0700 (PDT) Received: (qmail 25169 invoked by uid 399); 26 May 2011 22:47:06 -0000 Received: from unknown (HELO 65-241-43-5.globalsuite.net) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 26 May 2011 22:47:06 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DDED868.1000602@dougbarton.us> Date: Thu, 26 May 2011 15:47:04 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Smith Subject: Re: review of draft-ietf-node-req-bis References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com> <20110527065626.48a97f41@opy.nosense.org> <201105262130.p4QLUAQY020878@cichlid.raleigh.ibm.com> <20110527073327.2c5fee14@opy.nosense.org> In-Reply-To: <20110527073327.2c5fee14@opy.nosense.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , 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, 26 May 2011 22:47:10 -0000 On 05/26/2011 15:03, Mark Smith wrote: > Exactly. That's the problem. If you know you can't or aren't very > likely to be able to relay DHCP options to customer's end-nodes, you > don't bother sending them. The myriad of DHCP(v4 and v6) options that > exist that may be useful to an SP are currently of no or very little use > because they can't be conveyed directly to customer's end-nodes across > the CPE boundary. One could imagine a situation where the CPE makes configures itself with those options, and by default then transmits them to clients it acts as a server for. That is probably a different document though. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From james.cutler@consultant.com Thu May 26 18:32:31 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 827A3E06A5 for ; Thu, 26 May 2011 18:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_HELO_MAIL_COM_DOM=3.199] 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 I4Txbcs3AlO7 for ; Thu, 26 May 2011 18:32:11 -0700 (PDT) Received: from mailout-us.mail.com (mailout-us.mail.com [74.208.122.35]) by ietfa.amsl.com (Postfix) with SMTP id 568D0E0697 for ; Thu, 26 May 2011 18:32:11 -0700 (PDT) Received: (qmail invoked by alias); 27 May 2011 01:32:08 -0000 Received: from adsl-76-226-66-38.dsl.sfldmi.sbcglobal.net (EHLO minijim.local) [76.226.66.38] by mail.gmx.com (mp-us009) with SMTP; 26 May 2011 21:32:08 -0400 X-Authenticated: #76096295 X-Provags-ID: V01U2FsdGVkX1+838tj1yO8B3CnsrWbzJNSJbPYgLjkSLB27cNhcR ip/lxeHuUm5KMe Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Re: review of draft-ietf-node-req-bis From: Cutler James R In-Reply-To: <20110527065626.48a97f41@opy.nosense.org> Date: Thu, 26 May 2011 21:32:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <53823C28-7ED7-417E-9C7B-56EA03EBE2CE@consultant.com> References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com> <20110527065626.48a97f41@opy.nosense.org> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 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: Fri, 27 May 2011 01:32:31 -0000 On May 26, 2011, at 5:26 PM, Mark Smith wrote: > > I think relay should be a MUST. I want to see IPv6 achieve the same > level of autoconfiguration that previous protocols like Appletalk and > IPX achieved, which includes automated application/service parameter > configuration. If the application/service parameter source is off > link (i.e. an off-link DHCPv6 server), then currently the only way for > those options to passed opaquely to end-nodes via a router is via a > DHCPv6 relay capability. > I strongly concur with Mark re "MUST". It does not make sense to design = in limitations which would require CPE firmware updates or other extreme = measures to overcome later. If you feel strongly that DHCP relay should = be "off by default", by all means make it so. But, don't design away = the capability which some say that their business requires. IPv6 is supposed to be "just like IPv4, only better". Deliberately = crippled by design is not "better". James R. Cutler james.cutler@consultant.com From brian@innovationslab.net Fri May 27 05:07: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 66E0CE06BF for ; Fri, 27 May 2011 05:07: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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 WhrlDTUQd2dm for ; Fri, 27 May 2011 05:07:31 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id E8A0BE06BE for ; Fri, 27 May 2011 05:07:31 -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 C8A7F88241 for ; Fri, 27 May 2011 05:07:31 -0700 (PDT) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 707531368376 for ; Fri, 27 May 2011 05:07:31 -0700 (PDT) Message-ID: <4DDF9400.2020605@innovationslab.net> Date: Fri, 27 May 2011 08:07:28 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: review of draft-ietf-node-req-bis References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com><20110527065626.48a97f41@opy.nosense.org> <201105262130.p4QLUAQY020878@cichlid.raleigh.ibm.com> In-Reply-To: X-Enigmail-Version: 1.1.1 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: Fri, 27 May 2011 12:07:32 -0000 On 5/26/11 5:46 PM, Manfredi, Albert E wrote: > Thomas Narten wrote: > >> Let me ask a question. In IPv4, for typical SOHO routers, do they >> support DHCP relay agent functionality? (My guess is no.) >> >> And what about configuring it? It is *not* plug and play, zeroconf >> magic... > > Since they are typically NAPTs, I'd say no. They are local DHCP > servers for the private address space behind them only. > > In IPv6, what will the "typical SOHO router" look like, though? Same > NAT functionality as IPv4? And if not, is there an automatic way of > configuring this SOHO router for any possible DHCP relay function? What about a situation where rather than using DHCP relay, a router uses DHCP Prefix Delegation to get a prefix that is then used in the home network? There is no need for the relay functionality and the CPE is still plug-and-play. Regards, Brian From twinters@iol.unh.edu Fri May 27 05:11: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 7A824E06F5 for ; Fri, 27 May 2011 05:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 WN6FOrKJP8qZ for ; Fri, 27 May 2011 05:11:38 -0700 (PDT) Received: from exprod5og108.obsmtp.com (exprod5og108.obsmtp.com [64.18.0.186]) by ietfa.amsl.com (Postfix) with SMTP id 8BBB1E068F for ; Fri, 27 May 2011 05:11:37 -0700 (PDT) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob108.postini.com ([64.18.4.12]) with SMTP ID DSNKTd+U+Rc98GjB/GqIL2YvoXQnIKE+5Zii@postini.com; Fri, 27 May 2011 05:11:38 PDT Received: from openvpn-client3.iol.unh.edu (openvpn-client3.iol.unh.edu [132.177.124.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id 747B78F0066; Fri, 27 May 2011 08:11:36 -0400 (EDT) Subject: Re: review of draft-ietf-node-req-bis Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timothy Winters In-Reply-To: <4DDF9400.2020605@innovationslab.net> Date: Fri, 27 May 2011 08:11:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <22EADF94-1A90-41F4-B523-F328AE00CA2A@iol.unh.edu> References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com><20110527065626.48a97f41@opy.nosense.org> <201105262130.p4QLUAQY020878@cichlid.raleigh.ibm.com> <4DDF9400.2020605@innovationslab.net> To: Brian Haberman 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, 27 May 2011 12:11:39 -0000 Brian suggestion is what we've seen in all the CPE devices we've had at = the UNH-IOL last two CE Router Events. I haven't seen a CPE/SOHO router = act as a relay agent. Regards, Tim On May 27, 2011, at 8:07 AM, Brian Haberman wrote: > On 5/26/11 5:46 PM, Manfredi, Albert E wrote: >> Thomas Narten wrote: >>=20 >>> Let me ask a question. In IPv4, for typical SOHO routers, do they=20 >>> support DHCP relay agent functionality? (My guess is no.) >>>=20 >>> And what about configuring it? It is *not* plug and play, zeroconf=20= >>> magic... >>=20 >> Since they are typically NAPTs, I'd say no. They are local DHCP >> servers for the private address space behind them only. >>=20 >> In IPv6, what will the "typical SOHO router" look like, though? Same >> NAT functionality as IPv4? And if not, is there an automatic way of >> configuring this SOHO router for any possible DHCP relay function? >=20 > What about a situation where rather than using DHCP relay, a router = uses > DHCP Prefix Delegation to get a prefix that is then used in the home > network? There is no need for the relay functionality and the CPE is > still plug-and-play. >=20 > Regards, > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From v6ops@globis.net Fri May 27 05:39:25 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 981F6E0671 for ; Fri, 27 May 2011 05:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 IoD6S5+2QN6W for ; Fri, 27 May 2011 05:39:18 -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 1EA39E06BF for ; Fri, 27 May 2011 05:39:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E617C8700D5 for ; Fri, 27 May 2011 14:39:16 +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 c3ArEiEHi3UJ for ; Fri, 27 May 2011 14:39:11 +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 63D1D870023 for ; Fri, 27 May 2011 14:39:11 +0200 (CEST) Message-ID: <4DDF9B6F.1060108@globis.net> Date: Fri, 27 May 2011 14:39:11 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: review of draft-ietf-node-req-bis Content-Type: multipart/alternative; boundary="------------040503050002070204020402" 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, 27 May 2011 12:39:25 -0000 This is a multi-part message in MIME format. --------------040503050002070204020402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > Message: 2 > Date: Thu, 26 May 2011 16:21:59 -0400 > From: Thomas Narten > To:ipv6@ietf.org > Subject: Re: review of draft-ietf-node-req-bis > Message-ID:<201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com> > > Going back to this... > > Jari Arkko writes: > > > New text: > > 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 > > Because a single DHCP server can support devices on multiple links, > it is not necessary that every router support DHCPv6 directly. > However, in order to support DHCPv6 servers on other links, routers > SHOULD support relay agent functionality of DHCPv6 [RFC3315]. > Routers MAY support full [RFC3315] or stateless [RFC4862] DHCPv6 > server functionality as well. > > I'm on the fence wrt MAY/SHOULD on the recommendation above. I don't > think every router needs to support DHCP, hence the MAY. But SHOULD is > also not a MUST, so I'd be OK with SHOULD. > > Indeed, where one arguably should have a MUST is in relay agent > functionality. SHould I elevate it? > > Thoughts? > > Thomas > > All from my own very very humble opinion based on experiences mainly in enterprise networks. Many people have centralized DHCPv4 at least at the site level, if not the enterprise level, for very good and varied operational reasons (not just because they had to have them for allocating and registering names and addresses) and much of that functionality cannot currently be replaced by SLAAC alone (or any other widely deployed alternatives AFAIK). I was reminded just the other day of the (humble) origins in bootp when someone walked into the office and wanted to set the Code 67 boot_file_name and Code 66 boot_server in the DHCP scope for use by a server located on another remote site, which contacted the central DHCP server via DHCP relay. DHCPv6 server on a router is definitely not a must. Probably not even a should. MAY is absolutely fine for me. DHCPv6 relay on a router is definitely at least a SHOULD. Otherwise those centralized IPAM systems that exist today will not be able to function with IPv6: you will break existing functionality that enterprise network managers currently use to great extent. On the other hand, a MUST for DHCP relay on routers seems to go way too far for me. DHCPv6 support is after all only a SHOULD for end nodes. And it may not even be turned on by default. So what parameters are network operators expecting to set on an end node that is so important? I'd like it to be otherwise, but the truth seems to be that the current consensus is that there is no consensus on a single mechanism of how to signal options and settings between a network manager/ service provider and an end node. Personally, I won't buy a router without a DHCPv6 relay function. But then again in an SP environment with PD, where do you point DHCPv6 relay to by default to fetch content if it is a MUST? Does it serve local config parameters (set by the local admin to control e.g. printservers) or does it serve config parameters sent to the household end node systems by the Service Provider (which might be ignored by end nodes not running DHCPv6)? Who has the admin rights? Potential can of worms and source of conflict until the question is sorted out for each DHCPv6 option of who can set the value and which source is authoritative. So in summary, I'd settle for MAY for server, and SHOULD for relay. IMVVVVHO regards, RayH --------------040503050002070204020402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Message: 2
Date: Thu, 26 May 2011 16:21:59 -0400
From: Thomas Narten <narten@us.ibm.com>
To: ipv6@ietf.org
Subject: Re: review of draft-ietf-node-req-bis
Message-ID: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com>

Going back to this...

Jari Arkko <jari.arkko@piuha.net> writes:
<snip>

New text:

   12.3.  Stateful Address Autoconfiguration (DHCPv6) - RFC 3315

   Because a single DHCP server can support devices on multiple links,
   it is not necessary that every router support DHCPv6 directly.
   However, in order to support DHCPv6 servers on other links, routers
   SHOULD support relay agent functionality of DHCPv6 [RFC3315].
   Routers MAY support full [RFC3315] or stateless [RFC4862] DHCPv6
   server functionality as well.

I'm on the fence wrt MAY/SHOULD on the recommendation above. I don't
think every router needs to support DHCP, hence the MAY. But SHOULD is
also not a MUST, so I'd be OK with SHOULD.

Indeed, where one arguably should have a MUST is in relay agent
functionality. SHould I elevate it?

Thoughts?

Thomas

All from my own very very humble opinion based on experiences mainly in enterprise networks.

Many people have centralized DHCPv4 at least at the site level, if not the enterprise level, for very good and varied operational reasons (not just because they had to have them for allocating and registering names and addresses) and much of that functionality cannot currently be replaced by SLAAC alone (or any other widely deployed alternatives AFAIK).

I was reminded just the other day of the (humble) origins in bootp when someone walked into the office and wanted to set the Code 67 boot_file_name and Code 66 boot_server in the DHCP scope for use by a server located on another remote site, which contacted the central DHCP server via DHCP relay.

DHCPv6 server on a router is definitely not a must. Probably not even a should. MAY is absolutely fine for me.

DHCPv6 relay on a router is definitely at least a SHOULD. Otherwise those centralized IPAM systems that exist today will not be able to function with IPv6: you will break existing functionality that enterprise network managers currently use to great extent.

On the other hand, a MUST for DHCP relay on routers seems to go way too far for me. DHCPv6 support is after all only a SHOULD for end nodes. And it may not even be turned on by default.

So what parameters are network operators expecting to set on an end node that is so important?

I'd like it to be otherwise, but the truth seems to be that the current consensus is that there is no consensus on a single mechanism of how to signal options and settings between a network manager/ service provider and an end node.

Personally, I won't buy a router without a DHCPv6 relay function. But then again in an SP environment with PD, where do you point DHCPv6 relay to by default to fetch content if it is a MUST? Does it serve local config parameters (set by the local admin to control e.g. printservers) or does it serve config parameters sent to the household end node systems by the Service Provider (which might be ignored by end nodes not running DHCPv6)? Who has the admin rights? Potential can of worms and source of conflict until the question is sorted out for each DHCPv6 option of who can set the value and which source is authoritative.

So in summary, I'd settle for MAY for server, and SHOULD for relay. IMVVVVHO

regards,
RayH
--------------040503050002070204020402-- From bs7652@att.com Fri May 27 06:08:47 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 411CAE0700 for ; Fri, 27 May 2011 06:08:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxgITJnL4XTi for ; Fri, 27 May 2011 06:08:46 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 59231E06EC for ; Fri, 27 May 2011 06:08:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1306501724!19803072!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 29021 invoked from network); 27 May 2011 13:08:45 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 May 2011 13:08:45 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4RD7ddZ020897; Fri, 27 May 2011 09:07:39 -0400 Received: from 01GAF5142010624.AD.BLS.COM (01GAF5142010624.ad.bls.com [139.76.131.91]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with SMTP id p4RD7YF3020812; Fri, 27 May 2011 09:07:35 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 May 2011 09:08:14 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 May 2011 09:08:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: review of draft-ietf-node-req-bis Date: Fri, 27 May 2011 09:08:37 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F1C81AC1B@crexc50p> In-Reply-To: <22EADF94-1A90-41F4-B523-F328AE00CA2A@iol.unh.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of draft-ietf-node-req-bis Thread-Index: AcwcZzsypnhAFJ7RRXK5ep4cIVltAwAA6l/g References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com><20110527065626.48a97f41@opy.nosense.org> <201105262130.p4QLUAQY020878@cichlid.raleigh.ibm.com><4DDF9400.2020605@innovationslab.net> <22EADF94-1A90-41F4-B523-F328AE00CA2A@iol.unh.edu> From: "STARK, BARBARA H (ATTSI)" To: "Timothy Winters" , "Brian Haberman" X-OriginalArrivalTime: 27 May 2011 13:08:14.0823 (UTC) FILETIME=[236D8770:01CC1C6F] 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, 27 May 2011 13:08:47 -0000 I'm unaware of any member of the mass market community (which accounts for a whole lot of "nodes" and "routers") who are asking for or wanting or expecting DNCP Relay. That's SOHO, Consumer, or the ISPs that serve them. Are there specialized niches inside these communities that might like DHCP Relay? That could well be. But to suggest that the mass incur the expense of including DHCP Relay for the benefit of an unknown few is unrealistic.=20 Note that the CableLabs eRouter spec (Feb 2011) says=20 "The eRouter is not expected to implement: ... * Any relay agent functions." The Broadband Forum TR-124 Issue 2 makes no mention of DHCPv6 Relay, whatsoever. Assuming that these documents are a good indication of the functionality that major connectivity ISPs are expecting in IPv6-capable consumer (and mass market SOHO to a large extent) routers, I would say that it is almost a given that if you do make DHCP Relay a "MUST", this would be one "MUST" that will be blithely ignored by many. Including "MUST" recommendations that are going to be ignored severely weakens a document. I would recommend against it. I would also recommend against a "SHOULD", given the language (or lack of language) in the above mentioned documents. IMO, "MAY" is fine. Also, note that we have only just agreed to elevate support for DHCPv6 client in hosts from "MAY" to "SHOULD". If we can't expect hosts to support DHCPv6 as a "MUST" (and I quite agree with the "SHOULD" level there), then suggesting DHCPv6 Relay in routers be a "MUST" makes no sense to me. Barbara From rdroms.ietf@gmail.com Fri May 27 06:26:10 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 3B703E07E3 for ; Fri, 27 May 2011 06:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 nWdIdFUM3RsA for ; Fri, 27 May 2011 06:26:02 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 54011E06EC for ; Fri, 27 May 2011 06:26:02 -0700 (PDT) Received: by qwc23 with SMTP id 23so1225892qwc.31 for ; Fri, 27 May 2011 06:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=J4QN57RB6Cohs76As65LaIx4wzGKZkd64d7//32mp68=; b=Xwant1lj4HoDLZ7Fm2MCHivPe7eyiTKQgf6QJs6D/qrQw8L9Hhq2cJGdJSfl9IkoaV 2q75crTaOAsGZlBkxxFCjCzCNqXQW7d1liirNnGBZYPC1KR5VvBkE4crgrGgKUF2JUkN KvZviWQhdgfnbvbQidoJFAxQFMHqRuTvFQk1A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=VrJMqdaSYYAjTl0hNJH8EoBeKJD6rCvM46Wxv6hj3OnnhMiKdgt92+08Gqg03c7ucu Sx+01Ggq3w3U+bX3UjT2PWsuJlOvhwoXLysL2PjTILMEmT2UZ0UdMkIFm1jf+jv4AqC1 xCFil2dDT8l8RTceLlAn511PwPvS4FMJsAKtM= Received: by 10.224.189.71 with SMTP id dd7mr1638592qab.179.1306502761769; Fri, 27 May 2011 06:26:01 -0700 (PDT) Received: from [161.44.65.177] ([161.44.65.177]) by mx.google.com with ESMTPS id r32sm1085804qcs.14.2011.05.27.06.25.59 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2011 06:26:00 -0700 (PDT) Subject: Re: review of draft-ietf-node-req-bis Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F1C81AC1B@crexc50p> Date: Fri, 27 May 2011 09:25:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <34402336-E1EC-404B-AB35-5F51B9D83F68@gmail.com> References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com><20110527065626.48a97f41@opy.nosense.org> <201105262130.p4QLUAQY020878@cichlid.raleigh.ibm.com><4DDF9400.2020605@innovationslab.net> <22EADF94-1A90-41F4-B523-F328AE00CA2A@iol.unh.edu> <750BF7861EBBE048B3E648B4BB6E8F4F1C81AC1B@crexc50p> To: "ipv6@ietf.org Mailing List WG" X-Mailer: Apple Mail (2.1084) Cc: Brian Haberman , Ralph Droms 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, 27 May 2011 13:26:10 -0000 +1. It's highly unlikely that an SP wants to field DHCPv6 transactions = from all the devices in a subscriber network. We have adequate = mechanisms in place to get delegated prefixes and other config = information to the DHCPv6 server in the subscriber network without the = DHCPv6 relay function. I recommend "routers SHOULD support relay agent functionality of DHCPv6 = [RFC3315]." As Ray Hunter pointed out, the market will drive = implementation where needed: "I won't buy a router without a DHCPv6 = relay function." - Ralph On May 27, 2011, at 9:08 AM 5/27/11, STARK, BARBARA H (ATTSI) wrote: > I'm unaware of any member of the mass market community (which accounts > for a whole lot of "nodes" and "routers") who are asking for or = wanting > or expecting DNCP Relay. That's SOHO, Consumer, or the ISPs that serve > them. Are there specialized niches inside these communities that might > like DHCP Relay? That could well be. But to suggest that the mass = incur > the expense of including DHCP Relay for the benefit of an unknown few = is > unrealistic.=20 >=20 > Note that the CableLabs eRouter spec (Feb 2011) says=20 > "The eRouter is not expected to implement: > ... > * Any relay agent functions." >=20 > The Broadband Forum TR-124 Issue 2 makes no mention of DHCPv6 Relay, > whatsoever. >=20 > Assuming that these documents are a good indication of the = functionality > that major connectivity ISPs are expecting in IPv6-capable consumer = (and > mass market SOHO to a large extent) routers, I would say that it is > almost a given that if you do make DHCP Relay a "MUST", this would be > one "MUST" that will be blithely ignored by many. Including "MUST" > recommendations that are going to be ignored severely weakens a > document. I would recommend against it. >=20 > I would also recommend against a "SHOULD", given the language (or lack > of language) in the above mentioned documents. IMO, "MAY" is fine. >=20 > Also, note that we have only just agreed to elevate support for DHCPv6 > client in hosts from "MAY" to "SHOULD". If we can't expect hosts to > support DHCPv6 as a "MUST" (and I quite agree with the "SHOULD" level > there), then suggesting DHCPv6 Relay in routers be a "MUST" makes no > sense to me. > Barbara > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From bs7652@att.com Fri May 27 08:20:25 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 9077BE06F8 for ; Fri, 27 May 2011 08:20:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eovaZ3s11Kj for ; Fri, 27 May 2011 08:20:24 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id D681BE07F6 for ; Fri, 27 May 2011 08:20:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1306509619!19717217!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 26706 invoked from network); 27 May 2011 15:20:20 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 May 2011 15:20:20 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4RFJECZ031902; Fri, 27 May 2011 11:19:14 -0400 Received: from 01GAF5142010623.AD.BLS.COM (01GAF5142010623.ad.bls.com [139.76.131.87]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with SMTP id p4RFJAaU031852; Fri, 27 May 2011 11:19:11 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 May 2011 11:19:51 -0400 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 May 2011 11:19:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: review of draft-ietf-node-req-bis Date: Fri, 27 May 2011 11:20:14 -0400 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F1C81ADF5@crexc50p> In-Reply-To: <34402336-E1EC-404B-AB35-5F51B9D83F68@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of draft-ietf-node-req-bis Thread-Index: AcwccaculofJsMRSRMKjlmBUvrLBrAABNlBQ References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com><20110527065626.48a97f41@opy.nosense.org> <201105262130.p4QLUAQY020878@cichlid.raleigh.ibm.com><4DDF9400.2020605@innovationslab.net><22EADF94-1A90-41F4-B523-F328AE00CA2A@iol.unh.edu><750BF7861EBBE048B3E648B4BB6E8F4F1C81AC1B@crexc50p> <34402336-E1EC-404B-AB35-5F51B9D83F68@gmail.com> From: "STARK, BARBARA H (ATTSI)" To: "Ralph Droms" , X-OriginalArrivalTime: 27 May 2011 15:19:51.0034 (UTC) FILETIME=[85EFB5A0:01CC1C81] Cc: Brian Haberman 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, 27 May 2011 15:20:25 -0000 > +1. It's highly unlikely that an SP wants to field DHCPv6 transactions > from all the devices in a subscriber network. We have adequate > mechanisms in place to get delegated prefixes and other config > information to the DHCPv6 server in the subscriber network without the > DHCPv6 relay function. >=20 > I recommend "routers SHOULD support relay agent functionality of DHCPv6 > [RFC3315]." As Ray Hunter pointed out, the market will drive > implementation where needed: "I won't buy a router without a DHCPv6 > relay function." Hmm. I think maybe I need to be just a little stronger in my opposition to elevating the language around DHCPv6 Relay Agent. From a mass market service provider perspective, there are many cons to DHCPv6 Relay Agent, and no pros. In the world of mass market, scalability and capacity are very important. DHCP servers are scaled (and have the capacity) to function properly when there is a mass restoral of power after an outage that impacts many subscribers. If the number of devices sending DHCPv6 queries were increased many-fold, then this would increase the cost of DHCPv6 servers. In addition, the queries from hosts would likely get in the way of queries from routers requesting PDs. The routers need those PDs, and slowing down the PD process with lots of unnecessary and unwanted queries from hosts is a Bad Thing. Furthermore, if a router inside the home network requests a PD (many SPs will probably restrict PD assignment to 1 PD per subscriber) before the customer edge router does, then the customer's home network could end up in pretty bad shape. As evidenced by BBF and CableLabs docs, service providers are designing address assignment architecture around PD. Also, many end users (like me) would be very uncomfortable with having addresses for home network assigned directly from a service provider. Personally, I like to think I have some control over my home network. So DHCPv6 Relay Client for purpose of address assignment may actually be considered undesirable (by all parties involved) in a mass market environment. Furthermore, there is no need for DHCPv6 Relay Client for passing through options. The mechanisms that most service providers expect to see in routers is evident in RFC 6204: "L-12: The IPv6 CE router SHOULD make available a subset of DHCPv6 options (as listed in Section 5.3 of [RFC3736]) received from the DHCPv6 client on its WAN interface to its LAN-side DHCPv6 server." And TR-124i2: "LAN.DHCPv6S.10 The device SHOULD support Reconfigure Accept (RFC 3315) and pass the additional set of DHCP options received from the DHCP client on its WAN interface to IPv6 hosts." Given the above points, it's likely that many mass market service providers will actively prohibit DHCPv6 Relay Client from existing in the routers that they procure. You could argue that they could just disable it. But the reality is, that there is no need for it, and there could be harm if it were enabled (subscriber: "Ooh, what does this button do?"), so it's best not to have it at all. That saves on coding, testing, and risk of accidental enablement. For the IETF to strongly recommend implementing a function that a large segment of implementers is likely to actively prohibit doesn't seem like the right thing to do. And mandate of such a function, IMO, wouldn't serve the IETF well, at all. Barbara From rdroms.ietf@gmail.com Fri May 27 08:25:04 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 61486E06D3 for ; Fri, 27 May 2011 08:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 vsvWTB94DMjt for ; Fri, 27 May 2011 08:25:03 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C736EE06FE for ; Fri, 27 May 2011 08:25:02 -0700 (PDT) Received: by qwc23 with SMTP id 23so1295568qwc.31 for ; Fri, 27 May 2011 08:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=A59UCr65bO+7cUa7d56XjuT1xhsTCITKqEW8p38d+/w=; b=jwBrwJr2ZA6ZGiQ30lKunkeEwT5hY0GSBUkCWCc1dnJ7UPBwfposm/5YSC4QICcaJx cVaDJrxBJ6gj3u5JRhO8pbnJ7rQdSKUwFnZgA/xLjy2MQ5eiJ52PuT5PDSS52mtWQ8rj lhkZ1iQi7L+9lLgytu262aGkh2saHSttzNKCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=WBMgLQpi6N9Ml6W9HfAy6jZIczWewuV5GaF38Y26LA3MAQBtyu+NHck9MLOhlOGOl0 u/ALmnIxQO0pR6x+R4xdv0KdMGi4d3IupcQVHXMpEKFzCrKnax6vrWC+qjMSyHWPFUp1 p6BSffd44peZahEKyAMYg+fFO+FBzUDvO2Zto= Received: by 10.224.189.202 with SMTP id df10mr1634329qab.163.1306509902206; Fri, 27 May 2011 08:25:02 -0700 (PDT) Received: from [161.44.65.177] ([161.44.65.177]) by mx.google.com with ESMTPS id t28sm1143225qcs.29.2011.05.27.08.24.59 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2011 08:25:00 -0700 (PDT) Subject: Re: review of draft-ietf-node-req-bis Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F1C81ADF5@crexc50p> Date: Fri, 27 May 2011 11:24:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com><20110527065626.48a97f41@opy.nosense.org> <201105262130.p4QLUAQY020878@cichlid.raleigh.ibm.com><4DDF9400.2020605@innovationslab.net><22EADF94-1A90-41F4-B523-F328AE00CA2A@iol.unh.edu><750BF7861EBBE048B3E648B4BB6E8F4F1C81AC1B@crexc50p> <34402336-E1EC-404B-AB35-5F51B9D83F68@gmail.com> <750BF7861EBBE048B3E648B4BB6E8F4F1C81ADF5@crexc50p> To: "STARK, BARBARA H (ATTSI)" X-Mailer: Apple Mail (2.1084) Cc: Brian Haberman , ipv6@ietf.org, Ralph Droms 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, 27 May 2011 15:25:04 -0000 Barbara - sorry, I wasn't clear. I think we're in agreement. The = router at the edge of a subscriber network does not need the relay = function. There are other network architectures where the relay function is likely = to be needed. It's not clear a single RFC 2119 recommendation is = adequate. - Ralph On May 27, 2011, at 11:20 AM 5/27/11, STARK, BARBARA H (ATTSI) wrote: >> +1. It's highly unlikely that an SP wants to field DHCPv6 > transactions >> from all the devices in a subscriber network. We have adequate >> mechanisms in place to get delegated prefixes and other config >> information to the DHCPv6 server in the subscriber network without = the >> DHCPv6 relay function. >>=20 >> I recommend "routers SHOULD support relay agent functionality of > DHCPv6 >> [RFC3315]." As Ray Hunter pointed out, the market will drive >> implementation where needed: "I won't buy a router without a DHCPv6 >> relay function." >=20 > Hmm. I think maybe I need to be just a little stronger in my = opposition > to elevating the language around DHCPv6 Relay Agent. =46rom a mass = market > service provider perspective, there are many cons to DHCPv6 Relay = Agent, > and no pros. In the world of mass market, scalability and capacity are > very important. DHCP servers are scaled (and have the capacity) to > function properly when there is a mass restoral of power after an = outage > that impacts many subscribers. If the number of devices sending DHCPv6 > queries were increased many-fold, then this would increase the cost of > DHCPv6 servers. In addition, the queries from hosts would likely get = in > the way of queries from routers requesting PDs. The routers need those > PDs, and slowing down the PD process with lots of unnecessary and > unwanted queries from hosts is a Bad Thing. Furthermore, if a router > inside the home network requests a PD (many SPs will probably restrict > PD assignment to 1 PD per subscriber) before the customer edge router > does, then the customer's home network could end up in pretty bad = shape. >=20 > As evidenced by BBF and CableLabs docs, service providers are = designing > address assignment architecture around PD. Also, many end users (like > me) would be very uncomfortable with having addresses for home network > assigned directly from a service provider. Personally, I like to think = I > have some control over my home network. So DHCPv6 Relay Client for > purpose of address assignment may actually be considered undesirable = (by > all parties involved) in a mass market environment. >=20 > Furthermore, there is no need for DHCPv6 Relay Client for passing > through options. The mechanisms that most service providers expect to > see in routers is evident in RFC 6204: > "L-12: The IPv6 CE router SHOULD make available a subset of DHCPv6 > options (as listed in Section 5.3 of [RFC3736]) received from > the DHCPv6 client on its WAN interface to its LAN-side DHCPv6 > server." > And TR-124i2: > "LAN.DHCPv6S.10 The device SHOULD support Reconfigure Accept (RFC = 3315) > and pass the additional set of DHCP options received from the > DHCP client on its WAN interface to IPv6 hosts." >=20 > Given the above points, it's likely that many mass market service > providers will actively prohibit DHCPv6 Relay Client from existing in > the routers that they procure. You could argue that they could just > disable it. But the reality is, that there is no need for it, and = there > could be harm if it were enabled (subscriber: "Ooh, what does this > button do?"), so it's best not to have it at all. That saves on = coding, > testing, and risk of accidental enablement. >=20 > For the IETF to strongly recommend implementing a function that a = large > segment of implementers is likely to actively prohibit doesn't seem = like > the right thing to do. And mandate of such a function, IMO, wouldn't > serve the IETF well, at all. > Barbara From narten@us.ibm.com Fri May 27 10:51: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 C775FE084F for ; Fri, 27 May 2011 10:51:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77YVlFCNCV81 for ; Fri, 27 May 2011 10:51:48 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id 37AC6E084B for ; Fri, 27 May 2011 10:51:48 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p4RHe6Wa010710 for ; Fri, 27 May 2011 11:40:06 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p4RHpJu5067984 for ; Fri, 27 May 2011 11:51:34 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p4RBpJJi025374 for ; Fri, 27 May 2011 05:51:19 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-253-65.mts.ibm.com [9.65.253.65]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p4RBpIX1024986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 May 2011 05:51:19 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p4RHpBdo007827 for ; Fri, 27 May 2011 13:51:17 -0400 Message-Id: <201105271751.p4RHpBdo007827@cichlid.raleigh.ibm.com> To: ipv6@ietf.org Subject: Node Requirements: Revised text for DHCP on routers Date: Fri, 27 May 2011 13:51:11 -0400 From: Thomas Narten 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, 27 May 2011 17:51:48 -0000 Going through this thread, here is some proposed text. I've concluded that whether to require DHC and/or relay agents is much more nuances than a simple SHOULD/MAY/MUST. How about the following proposed wording: 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 A single DHCP server ([RFC3315] or[RFC4862]) can provide configuration information to devices directly attached to a shared link, as well as to devices located elsewhere within a site. Communication between a client and a DHCP server located on different links requires the use of DHCP relay agents on routers. In simple deployments, consisting of a single router and either a single LAN, or multiple LANs attached to the single router, together with a WAN connection, a DHCP server embedded within the router has been a common deployment scenario (e.g., [RFC6204]). However, there is no need for relay agents in such scenarios. In more complex deployment scenarios, such as within enterprise or service provider networks, the use of DHCP requires some level of configuration, in order to configure relay agents, DHCP servers, etc. In such environments, the DHCP server might even be run on a traditional server, rather than as part of a router. Because of the wide range of deployment scenarios, support for DHCP server on routers is optional. However, routers targetted for deployment within more complex scenarios (as described above) SHOULD support relay agent functionality. Note that "Basic Requirements for IPv6 Customer Edge Routers" [RFC6204] requires implementation of a DHCPv6 function in IPv6 CE routers. Thomas From rdroms.ietf@gmail.com Fri May 27 11:15:13 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 9381DE0843 for ; Fri, 27 May 2011 11:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 B1GqCAk+eyml for ; Fri, 27 May 2011 11:15:12 -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 CB6CFE082B for ; Fri, 27 May 2011 11:15:12 -0700 (PDT) Received: by qyk7 with SMTP id 7so1194312qyk.10 for ; Fri, 27 May 2011 11:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=JyuoHsztYHeqTsoeZipBwlNxgG/GlitLQm+GaEwwbpw=; b=pjT43NRaISGo1vcYlRo+MxX2Vwu7+jEPwIkj7hs6OVqc8nBV+7ya982YXm/DEnZ1AD HQdP0AbiyjcqAEYp9dl43MmLqSpMwCBVUlakSBxc1/CJ5kTBHxBDY43VEuYFaoHJlWtT 3q9NhcWOZmF+uH+aIrrK/jZ1Mw9qi6r9jhuFo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=iPtdMeomOSKzUCrBvHSuleqTl467iO0y3Z3ZP8noW02aUhkwM46LSVbIjSzQZ53dDU xUks1z35A2/bOs6+GmXC+s8UJB8fShAm3nqmW69SrxMTpvCjyQJ2UxNA3PtGkm+T/nSU +o8NFE5RVf369jBh/HERxewJYfjB+cb/4wXA0= Received: by 10.224.187.73 with SMTP id cv9mr1822130qab.26.1306520111011; Fri, 27 May 2011 11:15:11 -0700 (PDT) Received: from [161.44.65.177] ([161.44.65.177]) by mx.google.com with ESMTPS id p10sm1222401qcu.13.2011.05.27.11.15.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2011 11:15:10 -0700 (PDT) Subject: Re: Node Requirements: Revised text for DHCP on routers Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <201105271751.p4RHpBdo007827@cichlid.raleigh.ibm.com> Date: Fri, 27 May 2011 14:15:08 -0400 Content-Transfer-Encoding: 7bit Message-Id: <805BE3A0-3C96-4F94-92FA-21C34E185DEE@gmail.com> References: <201105271751.p4RHpBdo007827@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: "ipv6@ietf.org List WG Mailing" 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, 27 May 2011 18:15:13 -0000 Thomas - three small editorial suggestions: s/targetted/targeted/ In the last sentence, s/DHCPv6/DHCPv6 server/ For consistency, use either DHCPv6 or DHCP throughout. - Ralph On May 27, 2011, at 1:51 PM 5/27/11, Thomas Narten wrote: > Going through this thread, here is some proposed text. I've concluded > that whether to require DHC and/or relay agents is much more nuances > than a simple SHOULD/MAY/MUST. > > How about the following proposed wording: > > 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 > > A single DHCP server ([RFC3315] or[RFC4862]) can provide > configuration information to devices directly attached to a shared > link, as well as to devices located elsewhere within a site. > Communication between a client and a DHCP server located on different > links requires the use of DHCP relay agents on routers. > > In simple deployments, consisting of a single router and either a > single LAN, or multiple LANs attached to the single router, together > with a WAN connection, a DHCP server embedded within the router has > been a common deployment scenario (e.g., [RFC6204]). However, there > is no need for relay agents in such scenarios. > > In more complex deployment scenarios, such as within enterprise or > service provider networks, the use of DHCP requires some level of > configuration, in order to configure relay agents, DHCP servers, etc. > In such environments, the DHCP server might even be run on a > traditional server, rather than as part of a router. > > Because of the wide range of deployment scenarios, support for DHCP > server on routers is optional. However, routers targetted for > deployment within more complex scenarios (as described above) SHOULD > support relay agent functionality. Note that "Basic Requirements for > IPv6 Customer Edge Routers" [RFC6204] requires implementation of a > DHCPv6 function in IPv6 CE routers. > > > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From rdroms.ietf@gmail.com Fri May 27 11:16:28 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 BE921E080F for ; Fri, 27 May 2011 11:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.313 X-Spam-Level: X-Spam-Status: No, score=-103.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 jFjis0RzlUpM for ; Fri, 27 May 2011 11:16:28 -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 20144E0726 for ; Fri, 27 May 2011 11:16:28 -0700 (PDT) Received: by qyk7 with SMTP id 7so1194808qyk.10 for ; Fri, 27 May 2011 11:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=O+oDHSDLgflY3AAsMgbgCr0W8qAKFAT9neiOABPvoFU=; b=S5A/XQwkOXQR74/C1v4lzrU8cU/jvcr7SzuhiOjYKBLx1B7G2Ka2S2Y7qkqq3bIJ3H 6M1wEmRHsklpSYLpsgBPSUM7m0Mhw7+tNAYo81JkmjqKiicGVK598vMHBkNFHG+YjlDl U9zRgcsYWAPTJF/GKwWUZJhDR9Sm4ksfLOyCs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=gdo3DXNZmcEMmh9jK/RyIuwqm0V1UpANaKrTlLtCsVRZd0G16J5w+ee/yibtMT850i eRpFVSc3wQUGs9UTCHgpQC0XSCX1wQm5SPWp6zccts8JSWz0EWPq5O1BqxKjq/HpgGLM bPDUURl8qft2emHx6wCV7grGEt3lemIGTGsXk= Received: by 10.224.113.15 with SMTP id y15mr1776221qap.270.1306520187321; Fri, 27 May 2011 11:16:27 -0700 (PDT) Received: from [161.44.65.177] ([161.44.65.177]) by mx.google.com with ESMTPS id e28sm1223684qck.42.2011.05.27.11.16.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2011 11:16:26 -0700 (PDT) Subject: Re: Node Requirements: Revised text for DHCP on routers Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <201105271751.p4RHpBdo007827@cichlid.raleigh.ibm.com> Date: Fri, 27 May 2011 14:16:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201105271751.p4RHpBdo007827@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: "ipv6@ietf.org WG 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, 27 May 2011 18:16:28 -0000 BTW - I should have explicitly written explicitly that I think the text = is fine aside from the edits I suggested. - Ralph On May 27, 2011, at 1:51 PM 5/27/11, Thomas Narten wrote: > Going through this thread, here is some proposed text. I've concluded > that whether to require DHC and/or relay agents is much more nuances > than a simple SHOULD/MAY/MUST. >=20 > How about the following proposed wording: >=20 > 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 >=20 > A single DHCP server ([RFC3315] or[RFC4862]) can provide > configuration information to devices directly attached to a shared > link, as well as to devices located elsewhere within a site. > Communication between a client and a DHCP server located on = different > links requires the use of DHCP relay agents on routers. >=20 > In simple deployments, consisting of a single router and either a > single LAN, or multiple LANs attached to the single router, together > with a WAN connection, a DHCP server embedded within the router has > been a common deployment scenario (e.g., [RFC6204]). However, there > is no need for relay agents in such scenarios. >=20 > In more complex deployment scenarios, such as within enterprise or > service provider networks, the use of DHCP requires some level of > configuration, in order to configure relay agents, DHCP servers, = etc. > In such environments, the DHCP server might even be run on a > traditional server, rather than as part of a router. >=20 > Because of the wide range of deployment scenarios, support for DHCP > server on routers is optional. However, routers targetted for > deployment within more complex scenarios (as described above) SHOULD > support relay agent functionality. Note that "Basic Requirements = for > IPv6 Customer Edge Routers" [RFC6204] requires implementation of a > DHCPv6 function in IPv6 CE routers. >=20 >=20 > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From bob.hinden@gmail.com Fri May 27 11:35: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 73678E084A for ; Fri, 27 May 2011 11:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.511 X-Spam-Level: X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 VJjOo08TA+cK for ; Fri, 27 May 2011 11:35:56 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D923DE06F5 for ; Fri, 27 May 2011 11:35:56 -0700 (PDT) Received: by pzk5 with SMTP id 5so994721pzk.31 for ; Fri, 27 May 2011 11:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=nn6/4TC6P/WqW+Wg5Oksq1mm1/l2rulwp/l7/wZH8VY=; b=oFS0X6rErjcAB4N9JzbJTRWGGscYxRfd/bxXt9Hi6JNDHn/+BrSm9q26aaSyqRnyXE ixMsA/JGawe6tLEOjvMHgDCp3WYIO3sRQyUNoSD+W9JszdjzLfba/nmUjix64I3GZjxY 5+y84+igKZpLp9WUwu+PSUTK2k97Y07JKxsxI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=BX6VziFRhobxZ3Ycq0ZVgPmN5Ermn6E4sfDGnaVlweuCOFAU0U/nSRmtPwALmXswAx eGyOM2k/Q84mW1pHr4LbFD3vSyLxC7b3Dl5Y3F6Ur0dlZqH6keBM4AJuxZOlqzMERcav QyFMbA0o12QwY7+U7+dMi/eHDVZ71X+oNWjm8= Received: by 10.68.38.100 with SMTP id f4mr1007013pbk.126.1306521356338; Fri, 27 May 2011 11:35:56 -0700 (PDT) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id a6sm696260pbo.47.2011.05.27.11.35.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2011 11:35:55 -0700 (PDT) Subject: Re: Node Requirements: Revised text for DHCP on routers Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <201105271751.p4RHpBdo007827@cichlid.raleigh.ibm.com> Date: Fri, 27 May 2011 11:35:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201105271751.p4RHpBdo007827@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org, Bob Hinden 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, 27 May 2011 18:35:57 -0000 Thomas, Text looks fine to me (and Ralph's edits). I like that it makes clear = this is in an environment where DHCPv6 is being deployed. Bob On May 27, 2011, at 10:51 AM, Thomas Narten wrote: > Going through this thread, here is some proposed text. I've concluded > that whether to require DHC and/or relay agents is much more nuances > than a simple SHOULD/MAY/MUST. >=20 > How about the following proposed wording: >=20 > 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 >=20 > A single DHCP server ([RFC3315] or[RFC4862]) can provide > configuration information to devices directly attached to a shared > link, as well as to devices located elsewhere within a site. > Communication between a client and a DHCP server located on = different > links requires the use of DHCP relay agents on routers. >=20 > In simple deployments, consisting of a single router and either a > single LAN, or multiple LANs attached to the single router, together > with a WAN connection, a DHCP server embedded within the router has > been a common deployment scenario (e.g., [RFC6204]). However, there > is no need for relay agents in such scenarios. >=20 > In more complex deployment scenarios, such as within enterprise or > service provider networks, the use of DHCP requires some level of > configuration, in order to configure relay agents, DHCP servers, = etc. > In such environments, the DHCP server might even be run on a > traditional server, rather than as part of a router. >=20 > Because of the wide range of deployment scenarios, support for DHCP > server on routers is optional. However, routers targetted for > deployment within more complex scenarios (as described above) SHOULD > support relay agent functionality. Note that "Basic Requirements = for > IPv6 Customer Edge Routers" [RFC6204] requires implementation of a > DHCPv6 function in IPv6 CE routers. >=20 >=20 > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From albert.e.manfredi@boeing.com Fri May 27 12:05:53 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 9AD8DE0711 for ; Fri, 27 May 2011 12:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 6UpQ1qRsPTq7 for ; Fri, 27 May 2011 12:05:53 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id F1770E06A7 for ; Fri, 27 May 2011 12:05:52 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p4RJ5nrV024274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 May 2011 12:05:50 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p4RJ5mkv023075; Fri, 27 May 2011 12:05:49 -0700 (PDT) Received: from XCH-MWHT-02.mw.nos.boeing.com (xch-mwht-02.mw.nos.boeing.com [134.57.113.20]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p4RJ52Xw021462 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 27 May 2011 12:05:47 -0700 (PDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-02.mw.nos.boeing.com ([134.57.113.20]) with mapi; Fri, 27 May 2011 14:05:16 -0500 From: "Manfredi, Albert E" To: Brian Haberman , "ipv6@ietf.org" Date: Fri, 27 May 2011 14:05:14 -0500 Subject: RE: review of draft-ietf-node-req-bis Thread-Topic: review of draft-ietf-node-req-bis Thread-Index: AcwcZrjpdWAMahywSMKgt6xOlbRk8AAOYcaA Message-ID: References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com><2011052706 5626.48a97f41@opy.nosense.org> <201105262130.p4QLUAQY020878@cichlid.raleigh .ibm.com> <4DDF9400.2020605@innovationslab.net> In-Reply-To: <4DDF9400.2020605@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: Fri, 27 May 2011 19:05:53 -0000 Brian Haberman wrote: > > In IPv6, what will the "typical SOHO router" look like, though? Same > > NAT functionality as IPv4? And if not, is there an automatic way of > > configuring this SOHO router for any possible DHCP relay function? >=20 > What about a situation where rather than using DHCP relay, a router > uses > DHCP Prefix Delegation to get a prefix that is then used in the home > network? There is no need for the relay functionality and the CPE is > still plug-and-play. I agree that there are many possible ways to make this work. That's one of = them. My only point was, if DHCPv6 relay will become a MUST, then some other RFC = needs to be written to explain how this will be done in an interoperable wa= y, automatically, so that we aren't going to have to rely on manual configu= rations in these SOHO settings. Bert From rja.lists@gmail.com Fri May 27 15:51:13 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 200EFE068D for ; Fri, 27 May 2011 15:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 QMj29nI2u0Z2 for ; Fri, 27 May 2011 15:51:10 -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 0380BE0658 for ; Fri, 27 May 2011 15:51:09 -0700 (PDT) Received: by vws12 with SMTP id 12so2083393vws.31 for ; Fri, 27 May 2011 15:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=4sUJB2ZW1vXmC3STOYAEj8TYRGUYNBI8E+SbI+6DGLc=; b=v9RK7/UNhPvfRTpX1hbMWCpo67lrPoUoqRw1jVQ+ZQ30cYrqg4Csy6OKu41XpQqOq8 QNCBDzUZC9gaa/WXxhL3cBSNL3V7WIth7JNGdl15/H3Z7j8SvujugdffWLR4jifOyLMW 5SNwA9127vyumJuD55gfoqufUxzEndjmJf7lM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=KyDNJ77Hf2j6lMomjhSpsKeNIeOzpVZ+nGEexB9+PEyIuMPC7AmN67seQyMqTvsp7Y W1eAbECHxfjRkXo+77w4hZnZY78UZ/jsYSC9jaCqxSkco6Q+TAMd4byZBuKcyBsOFb1j Dwm6BGSlvqrbRtSa7W/xXOLg23Ttm8xxW6ens= Received: by 10.52.108.194 with SMTP id hm2mr3631221vdb.233.1306536669209; Fri, 27 May 2011 15:51:09 -0700 (PDT) Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id ck16sm261889vdb.20.2011.05.27.15.51.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2011 15:51:07 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: review of draft-ietf-node-req-bis Date: Fri, 27 May 2011 18:51:05 -0400 Message-Id: <303E1907-538D-4D22-974B-C8817C5B89A8@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 27 May 2011 22:51:13 -0000 Earlier Thomas Narten wrote in part: > Let me ask a question. In IPv4, for typical SOHO routers, do they > support DHCP relay agent functionality? (My guess is no.) Small office routers, such as the one in my garage, generally include DHCP relay agent capability and also have DHCP server capability (both static & dynamic). Low-cost home/consumer-electronics routers often have DHCP server capability (at least dynamic DHCP, sometimes also static DHCP) but generally do not have DHCP relay agent capability. > And what about configuring it? > It is *not* plug and play, zeroconf magic... Agreed. Note, however, that Dynamic DHCP server configuration can be done auto-magically in situations where the home router is performing NAT/NAPT-like transformations and the interior is using some private address space (192.168.X.*/24 is popular for several IPv4 home/ consumer-electronics routers). For IPv6, something similar could be auto-magical if ULAs were used on the interior, for example. Cheers, Ran From ipng@69706e6720323030352d30312d31340a.nosense.org Fri May 27 17:52:37 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 BAA2EE06BA for ; Fri, 27 May 2011 17:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 rqS7zhZabyWQ for ; Fri, 27 May 2011 17:52:37 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by ietfa.amsl.com (Postfix) with ESMTP id E929EE0618 for ; Fri, 27 May 2011 17:52:36 -0700 (PDT) Received: from 219-90-253-138.ip.adam.com.au ([219.90.253.138] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QQ7lT-0006HR-2u; Sat, 28 May 2011 10:22:27 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 44C423B338; Sat, 28 May 2011 10:22:26 +0930 (CST) Date: Sat, 28 May 2011 10:22:23 +0930 From: Mark Smith To: Doug Barton Subject: Re: review of draft-ietf-node-req-bis Message-ID: <20110528102223.13b081d9@opy.nosense.org> In-Reply-To: <4DDED868.1000602@dougbarton.us> References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com> <20110527065626.48a97f41@opy.nosense.org> <201105262130.p4QLUAQY020878@cichlid.raleigh.ibm.com> <20110527073327.2c5fee14@opy.nosense.org> <4DDED868.1000602@dougbarton.us> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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: Thomas Narten , 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: Sat, 28 May 2011 00:52:37 -0000 Hi Doug, On Thu, 26 May 2011 15:47:04 -0700 Doug Barton wrote: > On 05/26/2011 15:03, Mark Smith wrote: > > Exactly. That's the problem. If you know you can't or aren't very > > likely to be able to relay DHCP options to customer's end-nodes, you > > don't bother sending them. The myriad of DHCP(v4 and v6) options that > > exist that may be useful to an SP are currently of no or very little use > > because they can't be conveyed directly to customer's end-nodes across > > the CPE boundary. > > One could imagine a situation where the CPE makes configures itself with > those options, and by default then transmits them to clients it acts as > a server for. That is probably a different document though. > If the CPE doesn't understand the options, it can't pass them on. So if you look at the list of DHCPv6 options the are available - http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#dhcpv6-parameters-2 currently, using a DHCPv6 server in the CPE, none of them can be provided to end-nodes if the CPE doesn't support them, despite the SP's DHCPv6 server supporting them and the SP's customer's end-nodes supporting them. Only a DHCPv6 relay can effectively convey (relay) options it doesn't understand because it doesn't actually try to understand them. Regards, Mark. From dougb@dougbarton.us Fri May 27 18:04: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 9DC46E068C for ; Fri, 27 May 2011 18:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 CrivP0igJeIj for ; Fri, 27 May 2011 18:04:23 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 77549E0618 for ; Fri, 27 May 2011 18:04:23 -0700 (PDT) Received: (qmail 30572 invoked by uid 399); 28 May 2011 01:04:21 -0000 Received: from cpe-98-149-128-11.socal.res.rr.com (HELO 192-168-11-12.socal.rr.com) (dougb@dougbarton.us@98.149.128.11) by mail2.fluidhosting.com with ESMTPAM; 28 May 2011 01:04:21 -0000 X-Originating-IP: 98.149.128.11 X-Sender: dougb@dougbarton.us Message-ID: <4DE04A14.7060007@dougbarton.us> Date: Fri, 27 May 2011 18:04:20 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mark Smith Subject: Re: review of draft-ietf-node-req-bis References: <201105262021.p4QKLx2b020404@cichlid.raleigh.ibm.com> <20110527065626.48a97f41@opy.nosense.org> <201105262130.p4QLUAQY020878@cichlid.raleigh.ibm.com> <20110527073327.2c5fee14@opy.nosense.org> <4DDED868.1000602@dougbarton.us> <20110528102223.13b081d9@opy.nosense.org> In-Reply-To: <20110528102223.13b081d9@opy.nosense.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , 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: Sat, 28 May 2011 01:04:27 -0000 On 05/27/2011 17:52, Mark Smith wrote: > Hi Doug, > > On Thu, 26 May 2011 15:47:04 -0700 > Doug Barton wrote: > >> On 05/26/2011 15:03, Mark Smith wrote: >>> Exactly. That's the problem. If you know you can't or aren't very >>> likely to be able to relay DHCP options to customer's end-nodes, you >>> don't bother sending them. The myriad of DHCP(v4 and v6) options that >>> exist that may be useful to an SP are currently of no or very little use >>> because they can't be conveyed directly to customer's end-nodes across >>> the CPE boundary. >> >> One could imagine a situation where the CPE makes configures itself with >> those options, and by default then transmits them to clients it acts as >> a server for. That is probably a different document though. >> > > If the CPE doesn't understand the options, it can't pass them on. Well of course, yeah. > Only a DHCPv6 relay can effectively convey (relay) options it > doesn't understand because it doesn't actually try to understand them. I understand how relays work, but thanks. :) You're presuming however that both end users and SPs would want this behavior, and that both would want it in spite of it being dramatically different than what is done currently with IPv4. I don't think either of those is true, but I don't have research to back it up. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From v6ops@globis.net Fri May 27 21:41:18 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 78EDDE06F1 for ; Fri, 27 May 2011 21:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599] 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 PqKcU8BZ9yRn for ; Fri, 27 May 2011 21:41:18 -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 7EF9CE0618 for ; Fri, 27 May 2011 21:41:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7929E8700D9 for ; Sat, 28 May 2011 06:41:16 +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 SqPTpnACZ1QN for ; Sat, 28 May 2011 06:41:10 +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 78CDF870023 for ; Sat, 28 May 2011 06:41:10 +0200 (CEST) Message-ID: <4DE07CE6.4070304@globis.net> Date: Sat, 28 May 2011 06:41:10 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: ipv6@ietf.org Subject: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Sat, 28 May 2011 04:41:18 -0000 +1 Good text. Yes, it's much clearer now, and also answers my question of what DHCPv6 content service providers would want to serve to client end nodes on the customer's LAN. ;) Thanks RayH > ------------------------------ > > Message: 3 > Date: Fri, 27 May 2011 13:51:11 -0400 > From: Thomas Narten > To:ipv6@ietf.org > Subject: Node Requirements: Revised text for DHCP on routers > Message-ID:<201105271751.p4RHpBdo007827@cichlid.raleigh.ibm.com> > > Going through this thread, here is some proposed text. I've concluded > that whether to require DHC and/or relay agents is much more nuances > than a simple SHOULD/MAY/MUST. > > How about the following proposed wording: > > 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 > > A single DHCP server ([RFC3315] or[RFC4862]) can provide > configuration information to devices directly attached to a shared > link, as well as to devices located elsewhere within a site. > Communication between a client and a DHCP server located on different > links requires the use of DHCP relay agents on routers. > > In simple deployments, consisting of a single router and either a > single LAN, or multiple LANs attached to the single router, together > with a WAN connection, a DHCP server embedded within the router has > been a common deployment scenario (e.g., [RFC6204]). However, there > is no need for relay agents in such scenarios. > > In more complex deployment scenarios, such as within enterprise or > service provider networks, the use of DHCP requires some level of > configuration, in order to configure relay agents, DHCP servers, etc. > In such environments, the DHCP server might even be run on a > traditional server, rather than as part of a router. > > Because of the wide range of deployment scenarios, support for DHCP > server on routers is optional. However, routers targetted for > deployment within more complex scenarios (as described above) SHOULD > support relay agent functionality. Note that "Basic Requirements for > IPv6 Customer Edge Routers" [RFC6204] requires implementation of a > DHCPv6 function in IPv6 CE routers. > > > Thomas > > > From dougb@dougbarton.us Sun May 29 12:37:01 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 8735BE0745 for ; Sun, 29 May 2011 12:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.792 X-Spam-Level: X-Spam-Status: No, score=-3.792 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 FwDFlvkdnPYa for ; Sun, 29 May 2011 12:37:00 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECCDE0655 for ; Sun, 29 May 2011 12:37:00 -0700 (PDT) Received: (qmail 24203 invoked by uid 399); 29 May 2011 19:36:50 -0000 Received: from unknown (HELO ?65.241.43.5?) (dougb@dougbarton.us@65.241.43.5) by mail2.fluidhosting.com with ESMTPAM; 29 May 2011 19:36:50 -0000 X-Originating-IP: 65.241.43.5 X-Sender: dougb@dougbarton.us Message-ID: <4DE2A04B.5090400@dougbarton.us> Date: Sun, 29 May 2011 12:36:43 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Thomas Narten Subject: Re: Node Requirements: Revised text for DHCP on routers References: <201105271751.p4RHpBdo007827@cichlid.raleigh.ibm.com> In-Reply-To: <201105271751.p4RHpBdo007827@cichlid.raleigh.ibm.com> X-Enigmail-Version: 1.1.1 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: Sun, 29 May 2011 19:37:01 -0000 I think this is much better, and I would not object to the text as is (modulo Ralph's suggestions). I would like to make a couple of suggestions of my own for the middle two paragraphs that you should feel free to ignore. :) On 5/27/2011 10:51 AM, Thomas Narten wrote: > Going through this thread, here is some proposed text. I've concluded > that whether to require DHC and/or relay agents is much more nuances > than a simple SHOULD/MAY/MUST. > > How about the following proposed wording: > > 12.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 > > A single DHCP server ([RFC3315] or[RFC4862]) can provide > configuration information to devices directly attached to a shared > link, as well as to devices located elsewhere within a site. > Communication between a client and a DHCP server located on different > links requires the use of DHCP relay agents on routers. In simple deployments with a single router there is no need for a relay agent. A DHCP server embedded within the router is a common deployment scenario (e.g., [RFC6204]). In more complex deployment scenarios, such as within enterprise or service provider networks, use of DHCP may be more involved. For example configuration of relay agents, multiple DHCP servers, etc. In such environments the DHCP server might be run on a separate system, rather than as part of a router. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From hanauska@equinux.de Mon May 30 03:47: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 245CCE068E for ; Mon, 30 May 2011 03:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Daxo+aMWzAcy for ; Mon, 30 May 2011 03:47:21 -0700 (PDT) Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by ietfa.amsl.com (Postfix) with ESMTP id 14F10E0670 for ; Mon, 30 May 2011 03:47:20 -0700 (PDT) Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hsdg160171sc for ; Mon, 30 May 2011 11:14:58 +0200 (envelope-from ) Received: from mail.muc.equinux.net ([192.168.40.207]) by mail.equinux.net (equinux Secure mail Relay) with ESMTP; Mon, 30 May 2011 11:14:57 +0200 Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id 2C28F21C576F; Mon, 30 May 2011 12:47:19 +0200 (CEST) Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Markus Hanauska In-Reply-To: <20110524072631.737ee12c@opy.nosense.org> Date: Mon, 30 May 2011 12:47:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de> References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1084) X-Mlf-Version: 7.2.1.2841 X-Mlf-UniqueId: o201105300914570074328 Cc: Thomas Narten , "ipv6@ietf.org" , Ralph Droms 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, 30 May 2011 10:47:22 -0000 On 2011-05-23, at 23:56 , Mark Smith wrote: >> Christopher Morrow writes: >>=20 >> Just say that at startup time, invoke SLAAC & DHCPv6 both. Then use >> whatever is available. That would have been simple and >> predictable. (And avoided 10GB of mailing list discussion!) I'm totally with Christopher here. A flag is actually not necessary at = al IMHO. Considering the huge address space and the fact that an IPv6 = node usually has multiple addresses per interface anyway, one or two = additional addresses make no difference for the node or the network at a = whole. > What if both are available, Then a node has both, a SLAAC address and a DHCPv6 address. Where is the = problem? The only problem I can think of is the issue I was trying to = discuss here a couple of weeks ago: An address collision between SLAAC = addresses and non-SLAAC addresses. Normal SLAAC should never collide = with DHCP, since the 'u' bit is always 1 for a SLAAC address (globally = unique) but should be '0' for a DHCP address (not globally unique). Only = SLAAC with Privacy Extension could collide with DHCP (since it also has = a 'u' bit of 0) and I was told on this list "Don't worry, the address = space is so huge, this is probably never going to happen". I personally = would have preferred if the standards reserved an address range within = each /64 network that must not be used by SLAAC (regardless what kind of = SLAAC, it is taboo) and thus is safe for DHCP pools or manual assigned = addresses; however most people here seem to reject such an address = range (for reasons I cannot really understand, since it would not hurt = anyone in any way, but it could be pretty useful in real world = scenarios). > Conflict > resolution in these sorts of situations isn't always simple and > predictable. Conflict resolution is not really necessary. What kind of conflict do = you have to solve? If a network runs a DHCPv6 server that also hands out = addresses, the network operators probably want people to use DHCPv6 over = SLAAC, so if a host obtains both, an interface address via SLAAC and = DHCPv6, then it should prefer the DHCPv6 address for all outgoing = traffic, since if it uses the SLAAC address, a router may not forward = their traffic or a firewall may drop it. If a network runs a DHCPv6 = server, that does not hand out addresses (but possibly other useful = information), then the operators probably want you to use SLAAC to = obtain an address - in that case the system may use SLAAC or it may use = SLAAC with Privacy Extension for outgoing traffic. If no DHCP server is = present at all, SLAAC is your only option anyway. If there is a DHCP = server but it refuses to talk to you or hand out an address to you, it = is the same situation as if no such server was present. > I'm not particularly pro-SLAAC, however I sit back and wonder what is > missing from it that makes DHCP essential? The possibility to assign a specific address to a specific host, e.g. so = that forward and reverse DNS resolution works for this host and so that = you can create firewall rules on IP level. The same works with SLAAC, if = you can for sure predict the interface identifier, but it will fail if = privacy extension enters the game and also it means you have to update = lots of configs whenever the interface ID of a node changes (e.g. NIC = being replaced), in case of DHCP though, it is enough to store the new = MAC address in the DHCP config and still assign the same IP as before to = this host and everything will work as it used to. Sure, you can do the same thing by manually assigning IP addresses and = not use DHCP or SLAAC at all but being able to manage all this from a = central place (a single server that is DHCP server and DNS server at the = same time, for example) is much simpler and a lot less error-prone(!); = further if you want/have to change the assigned IP address of a single = host or group of hosts, it will be much easier. > It seems to me that the > functional reason people want DHCP is that they think it will track > address use - but it won't if end-nodes are manually assigned static > addresses. However, on most systems you need admin/root access to do any such thing = and normal computer users on those networks may not have those access = rights to their systems. Also intentionally breaking thinks like = forward/reverse DNS resolution has no advantages to the user, it only = has disadvantages, so why would he want to do so? The only reason I = could think of is bypassing firewall rules and for this, as mentioned = before, the user must have admin/root access and even that may not = really buy him something, since the firewall may drop any traffic from = an IP address that has not been assigned by DHCP. So the only thing the = user could do is manually assigning the DHCP address of another node to = his node... and this will fail, ND will prevent that from succeeding. Sure, you can argue "what if a user uses a custom Linux system, with a = custom kernel, that does not perform ND at all?"... but honestly, let's = not go too deep into the topic security, security is certainly not the = main argument for or against DHCP; I also doubt anyone ever said so. = High security networks are the 0.01% case of all IPv6 networks and they = may even require nodes to establish an IPSec tunnel to allow this host = to send any traffic anywhere at all and/or shield network ports through = VLANs and so on. Regards, Markus From pch-b2B3A6689@u-1.phicoh.com Mon May 30 04: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 0D092E078F for ; Mon, 30 May 2011 04:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 t+s-MRmrgAZ8 for ; Mon, 30 May 2011 04:04:34 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0A997E069A for ; Mon, 30 May 2011 04:04:34 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QR0Gr-0001gzC; Mon, 30 May 2011 13:04:29 +0200 Message-Id: To: Markus Hanauska Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de> In-reply-to: Your message of "Mon, 30 May 2011 12:47:19 +0200 ." <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de> Date: Mon, 30 May 2011 13:04:29 +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, 30 May 2011 11:04:35 -0000 In your letter dated Mon, 30 May 2011 12:47:19 +0200 you wrote: >Conflict resolution is not really necessary. What kind of conflict do you have > to solve? If a network runs a DHCPv6 server that also hands out addresses, th >e network operators probably want people to use DHCPv6 over SLAAC, so if a hos >t obtains both, an interface address via SLAAC and DHCPv6, then it should pref >er the DHCPv6 address for all outgoing traffic, since if it uses the SLAAC add >ress, a router may not forward their traffic or a firewall may drop it. There is an 'A-bit' in the Prefix Information option. I'd suggest that operators use that bit to control the assignment of SLAAC addresses. From v6ops@globis.net Mon May 30 13:05: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 084A3E07E4 for ; Mon, 30 May 2011 13:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 oZ6WQ8XqPzgh for ; Mon, 30 May 2011 13:05:28 -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 2A152E075B for ; Mon, 30 May 2011 13:05:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 5EE7D8700F1; Mon, 30 May 2011 22:05:24 +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 H8bbcEX+D-tf; Mon, 30 May 2011 22:05:15 +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 0F0498700D6; Mon, 30 May 2011 22:05:14 +0200 (CEST) Message-ID: <4DE3F87A.5060502@globis.net> Date: Mon, 30 May 2011 22:05:14 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Markus Hanauska Subject: Re: [ipv6] Node Requirements: Elevating DHCPv6 from MAY to SHOULD Content-Type: multipart/alternative; boundary="------------070904040003080903080008" Cc: Thomas Narten , ipv6@ietf.org, Ralph Droms 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, 30 May 2011 20:05:29 -0000 This is a multi-part message in MIME format. --------------070904040003080903080008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > > Message: 2 Date: Mon, 30 May 2011 12:47:19 +0200 From: Markus Hanauska > To: Mark Smith > Cc: Thomas Narten > , "ipv6@ietf.org" , Ralph Droms > Subject: Re: Node Requirements: Elevating > DHCPv6 from MAY to SHOULD Message-ID: > <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de> Content-Type: > text/plain; charset=us-ascii On 2011-05-23, at 23:56 , Mark Smith wrote: >>> >> Christopher Morrow writes: >>> >> >>> >> Just say that at startup time, invoke SLAAC& DHCPv6 both. Then use >>> >> whatever is available. That would have been simple and >>> >> predictable. (And avoided 10GB of mailing list discussion!) >>> > > I'm totally with Christopher here. A flag is actually not necessary at al IMHO. Considering the huge address space and the fact that an IPv6 node usually has multiple addresses per interface anyway, one or two additional addresses make no difference for the node or the network at a whole. Which source address (SLAAC/DHCPv6) would be used by the client for an outbound session if a SLAAC address and a DHCPv6 were both configured on the same link and with the same prefix, in the absence of a flag? Think dynamic DNS too: which (destination) address(es) would be auto registered at the server end? The main argument I'd make for network managers being able to predictably choose for centrally administered static addresses via DHCPv6 if they want to, is to be able to preserve existing semi-backward-compatible behavior similar to IPv4 + DHCPv4 + DHCP relay (which I realize is far from perfect). There are a lot of operational people who currently rely on having predictable IP addresses for accounting, audit, scripting, firewall rules, neighbor filtering, fault tracing, reverse DNS, policy based routing, setting DSCP in QoS, any other number of ACL's .... (completely putting to one side any argument whether that is good or bad practice, or whether there are now better solutions to achieve these effects) In summary, I'll be happy if any new proposal can still mimic semi-backward-compatible behavior of IPv4 + DHCPv4. regards, RayH --------------070904040003080903080008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Message: 2
Date: Mon, 30 May 2011 12:47:19 +0200
From: Markus Hanauska <hanauska@equinux.de>
To: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
Cc: Thomas Narten <narten@us.ibm.com>, "ipv6@ietf.org"
	<ipv6@ietf.org>,	Ralph Droms <rdroms.ietf@gmail.com>
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Message-ID: <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>
Content-Type: text/plain; charset=us-ascii


On 2011-05-23, at 23:56 , Mark Smith wrote:


>> Christopher Morrow <christopher.morrow@gmail.com> writes:
>> 
>> Just say that at startup time, invoke SLAAC & DHCPv6 both. Then use
>> whatever is available. That would have been simple and
>> predictable. (And avoided 10GB of mailing list discussion!)
      

I'm totally with Christopher here. A flag is actually not necessary at al IMHO. Considering the huge address space and the fact that an IPv6 node usually has multiple addresses per interface anyway, one or two additional addresses make no difference for the node or the network at a whole.
Which source address (SLAAC/DHCPv6) would be used by the client for an outbound session if a SLAAC address and a DHCPv6 were both configured on the same link and with the same prefix, in the absence of a flag? Think dynamic DNS too: which (destination) address(es) would be auto registered at the server end?

The main argument I'd make for network managers being able to predictably choose for centrally administered static addresses via DHCPv6 if they want to, is to be able to preserve existing semi-backward-compatible behavior similar to IPv4 + DHCPv4 + DHCP relay (which I realize is far from perfect). There are a lot of operational people who currently rely on having predictable IP addresses for accounting, audit, scripting, firewall rules, neighbor filtering, fault tracing, reverse DNS, policy based routing, setting DSCP in QoS, any other number of ACL's  .... (completely putting to one side any argument whether that is good or bad practice, or whether there are now better solutions to achieve these effects)

In summary, I'll be happy if any new proposal can still mimic semi-backward-compatible behavior of IPv4 + DHCPv4.

regards,
RayH

--------------070904040003080903080008-- From pch-b2B3A6689@u-1.phicoh.com Mon May 30 13:27: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 9E5F1E0688 for ; Mon, 30 May 2011 13:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_PRBLMS=2.3, RCVD_IN_DNSWL_MED=-4] 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 meTNATlWRKoD for ; Mon, 30 May 2011 13:27:29 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEB0E067F for ; Mon, 30 May 2011 13:27:29 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QR93e-0001IXC; Mon, 30 May 2011 22:27:26 +0200 Message-Id: To: Markus Hanauska Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD From: Philip Homburg Sender: pch-b2B3A6689@u-1.phicoh.com References: <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com> <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de> In-reply-to: Your message of "Mon, 30 May 2011 12:47:19 +0200 ." <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de> Date: Mon, 30 May 2011 22:27:16 +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, 30 May 2011 20:27:32 -0000 In your letter dated Mon, 30 May 2011 12:47:19 +0200 you wrote: >Then a node has both, a SLAAC address and a DHCPv6 address. Where is the probl >em? The only problem I can think of is the issue I was trying to discuss here >a couple of weeks ago: An address collision between SLAAC addresses and non-SL >AAC addresses. Normal SLAAC should never collide with DHCP, since the 'u' bit >is always 1 for a SLAAC address (globally unique) but should be '0' for a DHCP > address (not globally unique). Only SLAAC with Privacy Extension could collid >e with DHCP (since it also has a 'u' bit of 0) and I was told on this list "Do >n't worry, the address space is so huge, this is probably never going to happe >n". If you are really worried about this, then I guess you can also just assign two prefixes to a single link and use one for SLAAC and the other for DHCPv6. From brian.e.carpenter@gmail.com Mon May 30 14:12:14 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 86C54E06B5 for ; Mon, 30 May 2011 14:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.589 X-Spam-Level: X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 CUJvuB+kkTq7 for ; Mon, 30 May 2011 14:12:13 -0700 (PDT) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id C5997E0676 for ; Mon, 30 May 2011 14:12:13 -0700 (PDT) Received: by pxi20 with SMTP id 20so2696799pxi.27 for ; Mon, 30 May 2011 14:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Nk998+NOcW3jueWtd+fsTECLt/lFyCf4wfjtL51A3dk=; b=Y2LS5XBWl/RJfLDQDJotD/uYa816loEbQhW9E108+E3KPOgzMG4eX1jF5mDQOanabV 2421HJwd7j1dwnH5VlfquB3nWZ8/iG81xF81HR8LKwzzwV1WHP4CL+LMoxfNtgB+GTi8 m7yl/rjhReMYanWOzIoh0fuvflhamspL1X7sQ= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Wml78GsG0F/eB95PhsoJl068ZT+ySe1WFakB++ms8Ru280CsjFOAyA9haj8Iy4ik1m rm1kiRgQZosklsPgvHwEZfujVkk538/tfxa28X8mu0jKeREoEe249rmEZvpv+WozDSR8 7BaCkpiSrr6wdvPJZKuBN8Puknu6giSctknuw= Received: by 10.68.24.136 with SMTP id u8mr1236317pbf.285.1306789933528; Mon, 30 May 2011 14:12:13 -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 c5sm3131789pbj.73.2011.05.30.14.12.10 (version=SSLv3 cipher=OTHER); Mon, 30 May 2011 14:12:12 -0700 (PDT) Message-ID: <4DE40821.9030205@gmail.com> Date: Tue, 31 May 2011 09:12:01 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter Subject: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD] References: <4DE3F87A.5060502@globis.net> In-Reply-To: <4DE3F87A.5060502@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , ipv6@ietf.org, Ralph Droms 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, 30 May 2011 21:12:14 -0000 Ray, On 2011-05-31 08:05, Ray Hunter wrote: ... > Which source address (SLAAC/DHCPv6) would be used by the client for an > outbound session if a SLAAC address and a DHCPv6 were both configured on > the same link and with the same prefix, in the absence of a flag? Whichever RFC3484bis or the local policy table determines; this is orthogonal to the question of where the addresses come from. > Think > dynamic DNS too: which (destination) address(es) would be auto > registered at the server end? Both, if it's a server and you've chosen to use dynamic address allocation for servers. Again, this is orthogonal to where the addresses come from. It's going to be SOP for servers with multiple addresses. > The main argument I'd make for network managers being able to > predictably choose for centrally administered static addresses via > DHCPv6 if they want to, is to be able to preserve existing > semi-backward-compatible behavior similar to IPv4 + DHCPv4 + DHCP relay > (which I realize is far from perfect). There are a lot of operational > people who currently rely on having predictable IP addresses for > accounting, audit, scripting, firewall rules, neighbor filtering, fault > tracing, reverse DNS, policy based routing, setting DSCP in QoS, any > other number of ACL's .... (completely putting to one side any argument > whether that is good or bad practice, or whether there are now better > solutions to achieve these effects) Yes, there are lots of bad habits that have grown up over the years that IPv6 challenges. For example, setting the DSCP *as a function of the source address* makes me cringe. We're going to have to get used to the fact that IP addresses are not constants. Brian From fred@cisco.com Mon May 30 14:25:38 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 C7088E067F for ; Mon, 30 May 2011 14:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.241 X-Spam-Level: X-Spam-Status: No, score=-110.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 L-EhVCyC5HRx for ; Mon, 30 May 2011 14:25:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0B6E0676 for ; Mon, 30 May 2011 14:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=389; q=dns/txt; s=iport; t=1306790734; x=1308000334; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=FgDgPpTRSl2nWNUJHFfPdF2ASh9lnuPwjOB+lADZxbU=; b=WC/9JjE5CP65FFICe/o5r6wcou37dUuH2+MeDZlIupXPx2OXVGdV6Qza W0Hbh3oAdHf3jMENWGhPol4/T6KAHXrRIdzPdkqxSCSRovCQpdhIMYMOr JPJUrk+RhotGC4xPD4cJcrjI3OsolYv79qJqh1HCufkj+TNq4+qtkamSf c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACYK5E2rRDoJ/2dsb2JhbABHDqYqd4hxnXGdQoMXgwcEhmSJa4Q+inw X-IronPort-AV: E=Sophos;i="4.65,293,1304294400"; d="scan'208";a="705420761" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 30 May 2011 21:25:34 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4ULOT4q015132; Mon, 30 May 2011 21:25:34 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Mon, 30 May 2011 14:25:34 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Mon, 30 May 2011 14:25:34 -0700 Subject: Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD] Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4DE40821.9030205@gmail.com> Date: Mon, 30 May 2011 14:25:33 -0700 Message-Id: References: <4DE3F87A.5060502@globis.net> <4DE40821.9030205@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Thomas Narten , Ray Hunter , ipv6@ietf.org, Ralph Droms 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, 30 May 2011 21:25:38 -0000 On May 30, 2011, at 2:12 PM, Brian E Carpenter wrote: > For example, setting the DSCP *as a function of > the source address* makes me cringe. We're going to have to get used = to > the fact that IP addresses are not constants. good grief. The only reasonable use of a DSCP is to identify the set of = requirements the application has. It has nothing to do with the address.= From v6ops@globis.net Mon May 30 15:57:47 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 31228E06E6 for ; Mon, 30 May 2011 15:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6] 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 gaWRNvcZ15if for ; Mon, 30 May 2011 15:57:46 -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 2E5ACE0676 for ; Mon, 30 May 2011 15:57:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6BD1D8700D6; Tue, 31 May 2011 00:57:43 +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 HoLvfg8RpbLi; Tue, 31 May 2011 00:57:38 +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 6A6CF8700B2; Tue, 31 May 2011 00:57:38 +0200 (CEST) Message-ID: <4DE420E2.6010207@globis.net> Date: Tue, 31 May 2011 00:57:38 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Brian E Carpenter , ipng@69706e6720323030352d30312d31340a.nosense.org Subject: Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD] References: <4DE3F87A.5060502@globis.net> <4DE40821.9030205@gmail.com> In-Reply-To: <4DE40821.9030205@gmail.com> Content-Type: multipart/alternative; boundary="------------050008090605060808060808" Cc: Thomas Narten , ipv6@ietf.org, Ralph Droms 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, 30 May 2011 22:57:47 -0000 This is a multi-part message in MIME format. --------------050008090605060808060808 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit This is danger of going off topic I know (maybe it should go in v6ops), but it's important to me to be able to understand the consequences of the discussion, so please bear with me. It's definitely going to become an operational FAQ, unless it is very clear whether/how a network operator can force equivalent use of DHCPv4 static address assignment for both source and destination addresses via DHCPv6 (possibly by turning off SLAAC for assignment of GUA on an interface via a flag, or via RFC3484 bis), and how to achieve this effect for all nodes on a link, without resorting to local configuration. So I may as well the first to ask. Brian E Carpenter wrote: > Ray, > > On 2011-05-31 08:05, Ray Hunter wrote: > ... > >> Which source address (SLAAC/DHCPv6) would be used by the client for an >> outbound session if a SLAAC address and a DHCPv6 were both configured on >> the same link and with the same prefix, in the absence of a flag? >> > > Whichever RFC3484bis or the local policy table determines; > this is orthogonal to the question of where the addresses come from. > > Hmm. That's the conclusion I also came to myself already if there were no flags. So how would you prefer DHCPv6 (centrally) assigned addresses as opposed to SLAAC EUI64 addresses derived from MAC BIA ? Is this still an open issue, and I should just be patient? Would you have to set a prefix for every single DHCP range in RFC3484, and make sure the DHCPv6 assigned range did not overlap with likely EUI64 derived addresses to be able to guarantee that the DHCPv6 assigned address will be preferred? Or would you have to double the amount of entries in the ACL for both the DHCPv6 address and the SLAAC address (coded to MAC address) Or will RFC3484 bis be updated to include this behavior by automatically guessing which addresses are SLAAC addresses and which are DHCPv6 addresses and allow users to prefer DHCPv6 addresses? Bearing in mind destination address selection is also affected, so it might have to be able to remotely 'guess' what is a SLAAC address versus a DHCPv6 assigned address. [I checked the RFC 3484 bis list and there is no text today in version 02 http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02 nor anything proposed to cover this case in emails] see http://www.ietf.org/mail-archive/web/ipv6/current/msg13878.html for the last note. > I'll send a query to the ipv6-ops list just to see if this is a common expectation. The answer to the operational question: Yes IMHO there is a very clear operational expectation of being able to easily achieve DHCPv4 like behavior using DHCPv6, and this is hot operational topic. Some people have 50000 rules in their firewalls today. They won't thank anyone for 100K rules (to support both SLAAC+DHCPv6), or 50K rules that may change every time a NIC card fails (SLAAC only). >> Think >> dynamic DNS too: which (destination) address(es) would be auto >> registered at the server end? >> > > Both, if it's a server and you've chosen to use dynamic address > allocation for servers. Again, this is orthogonal to where > the addresses come from. It's going to be SOP for servers with > multiple addresses. > > > > Yes, there are lots of bad habits that have grown up over the years > that IPv6 challenges. For example, setting the DSCP *as a function of > the source address* makes me cringe. We're going to have to get used to > the fact that IP addresses are not constants. > > Brian > > In the meantime, we have to continue to operate networks whilst transitioning. As I asked, regardless of whether we think it's good or bad practice, I can assure you that it's certainly _common_ practice. Pretty much everyone I know who implements MPLS DSCP based QoS networks does it via IP based ACL's to overwrite DSCP on network ingress. offtopic: on the longer term, please give us some alternatives to manage and signal identities and QoS policies that are widely implemented by all manufacturers and all network providers. No 2 MPLS networks I know of use the same DSCP settings. Applications generally only set DSCP= EF on voice traffic. Everything else you have no standard signaling mechanism. It's rare for two OS'es to behave exactly the same way today. Same with 2 applications. In the absence of anything better, people get stuck on the lowest common denominator (IP address) and network ingress re-writing. Anyway for some operations it really isn't so bad: think of a few traveling VIP users who need a bit better service without spending a fortune on 802.1X or additional fancy multi-SSID wireless VLANs. Think well managed server farm and private network where there's a bulk back up server (all traffic placed in D3 class) next to an interactive software licence in server (all traffic placed in D1 class) and the rest of the traffic in D2. These guys are sometimes more worried about pure performance and cost and ease of management, rather than theft of service, re-writing apps etc. etc. Not necessarily nice. But operational reality. regards, RayH --------------050008090605060808060808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit This is danger of going off topic I know (maybe it should go in v6ops), but it's important to me to be able to understand the consequences of the discussion, so please bear with me. It's definitely going to become an operational FAQ, unless it is very clear whether/how a network operator can force equivalent use of DHCPv4 static address assignment for both source and destination addresses via DHCPv6 (possibly by turning off SLAAC for assignment of GUA on an interface via a flag, or via RFC3484 bis), and how to achieve this effect for all nodes on a link, without resorting to local configuration. So I may as well the first to ask.

Brian E Carpenter wrote: 
Ray,

On 2011-05-31 08:05, Ray Hunter wrote:
...
  
Which source address (SLAAC/DHCPv6) would be used by the client for an
outbound session if a SLAAC address and a DHCPv6 were both configured on
the same link and with the same prefix, in the absence of a flag? 
    

Whichever RFC3484bis or the local policy table determines;
this is orthogonal to the question of where the addresses come from.
Hmm. That's the conclusion I also came to myself already if there were no flags.

So how would you prefer DHCPv6 (centrally) assigned addresses as opposed to SLAAC EUI64 addresses derived from MAC BIA ?

Is this still an open issue, and I should just be patient?

Would you have to set a prefix for every single DHCP range in RFC3484, and make sure the DHCPv6 assigned range did not overlap with likely EUI64 derived addresses to be able to guarantee that the DHCPv6 assigned address will be preferred?

Or would you have to double the amount of entries in the ACL for both the DHCPv6 address and the SLAAC address (coded to MAC address)

Or will RFC3484 bis be updated to include this behavior by automatically guessing which addresses are SLAAC addresses and which are DHCPv6 addresses and allow users to prefer DHCPv6 addresses?

Bearing in mind destination address selection is also affected, so it might have to be able to remotely 'guess' what is a SLAAC address versus a DHCPv6 assigned address. [I checked the RFC 3484 bis list and there is no text today in version 02 http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02 nor anything proposed to cover this case in emails]

see http://www.ietf.org/mail-archive/web/ipv6/current/msg13878.html for the last note.

> I'll send a query to the ipv6-ops list just to see if this is a common expectation.

The answer to the operational question: Yes IMHO there is a very clear operational expectation of being able to easily achieve DHCPv4 like behavior using DHCPv6, and this is hot operational topic.

Some people have 50000 rules in their firewalls today. They won't thank anyone for 100K rules (to support both SLAAC+DHCPv6), or 50K rules that may change every time a NIC card fails (SLAAC only).



  

    
Think
dynamic DNS too: which (destination) address(es) would be auto
registered at the server end?
    

  

  

Both, if it's a server and you've chosen to use dynamic address
allocation for servers. Again, this is orthogonal to where
the addresses come from. It's going to be SOP for servers with
multiple addresses.

  



<snip>


  

Yes, there are lots of bad habits that have grown up over the years
that IPv6 challenges. For example, setting the DSCP *as a function of
the source address* makes me cringe. We're going to have to get used to
the fact that IP addresses are not constants.

    Brian

  



In the meantime, we have to continue to operate networks whilst
transitioning.



As I asked, regardless of whether we think it's good or bad practice, I
can assure you that it's certainly _common_ practice. Pretty much
everyone I know who implements MPLS DSCP based QoS networks does it via
IP based ACL's to overwrite DSCP on network ingress.



offtopic: on the longer term, please give us some alternatives to
manage and signal identities and QoS policies that are widely
implemented by all manufacturers and all network providers. No 2 MPLS
networks I know of use the same DSCP settings. Applications generally
only set DSCP= EF on voice traffic. Everything else you have no
standard signaling mechanism. It's rare for two OS'es to behave exactly
the same way today. Same with 2 applications. In the absence of
anything better, people get stuck on the lowest common denominator (IP
address) and network ingress re-writing.



Anyway for some operations it really isn't so bad: think of a few
traveling VIP users who need a bit better service without spending a
fortune on 802.1X or additional fancy multi-SSID wireless VLANs. Think
well managed server farm and private network where there's a bulk back
up server (all traffic placed in D3 class) next to an interactive
software licence in server (all traffic placed in D1 class) and the
rest of the traffic in D2. These guys are sometimes more worried about
pure performance and cost and ease of management, rather than theft of
service, re-writing apps etc. etc.



Not necessarily nice. But operational reality.



regards,

RayH




--------------050008090605060808060808--

From fred@cisco.com  Mon May 30 19:38: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 A32CDE065D for ; Mon, 30 May 2011 19:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.968
X-Spam-Level: 
X-Spam-Status: No, score=-109.968 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 X9I1W-FOhJIh for ; Mon, 30 May 2011 19:38:57 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6B870E0658 for ; Mon, 30 May 2011 19:38:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=6689; q=dns/txt; s=iport; t=1306809537; x=1308019137; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=IQtNewCWRK96cAlEakO3CqKkm5havQigPRAIIbZBqFo=; b=TcWT53GbVibg6XYyoXM0hWd+IA7Jfu1xgCGDb//C/I3YTSVO3XjPo7XY y3Vij5PmK/skQ51RjggROOsSRGsInqLu2mcOb/M33huuVhvDGC4ca0+2T efjxgRbJ1+4QJqbhTYeyesQ+OQUwKevq4ou8/wqa55vTX46wWg+EO0moB 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAMRT5E2rRDoH/2dsb2JhbABSpip3iHGdTp1Khh4EhmSJa4Q+inw
X-IronPort-AV: E=Sophos;i="4.65,295,1304294400"; d="scan'208";a="456719674"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 31 May 2011 02:38:57 +0000
Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4V2coNm005124; Tue, 31 May 2011 02:38:56 GMT
Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Mon, 30 May 2011 19:38:56 -0700
X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Mon, 30 May 2011 19:38:56 -0700
Subject: Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: <4DE420E2.6010207@globis.net>
Date: Mon, 30 May 2011 19:38:40 -0700
Message-Id: <4BC7CABA-D871-4B27-96BA-10A2F9D6D2B1@cisco.com>
References: <4DE3F87A.5060502@globis.net> <4DE40821.9030205@gmail.com> <4DE420E2.6010207@globis.net>
To: Ray Hunter 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Narten , ipv6@ietf.org, Brian E Carpenter , Ralph Droms 
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, 31 May 2011 02:38:58 -0000

On May 30, 2011, at 3:57 PM, Ray Hunter wrote:

> This is danger of going off topic I know (maybe it should go in =
v6ops), but it's important to me to be able to understand the =
consequences of the discussion, so please bear with me. It's definitely =
going to become an operational FAQ, unless it is very clear whether/how =
a network operator can force equivalent use of DHCPv4 static address =
assignment for both source and destination addresses via DHCPv6 =
(possibly by turning off SLAAC for assignment of GUA on an interface via =
a flag, or via RFC3484 bis), and how to achieve this effect for all =
nodes on a link, without resorting to local configuration. So I may as =
well the first to ask.

link-local will use SLAAC no matter what. It just does.

I'll let Ralph or one of the other RFC 3315 authors comment on DHCPv6, =
as they knows a lot more about it than I.=20

I would expect, however, that the use of DHCP is something configured on =
the system in question, just like it is in IPv4. Not that there is an =
auto-configure option in IPv4 - the other alternative is manual =
configuration, and most systems come with DHCP configured as the =
default. IPv6 systems come, at least today, with SLAAC as the default. =
So there is a requirement to configure DHCPv6, at least from that =
perspective. That said, SLAAC ain't gonna happen in the absence of RAs, =
and you can disable RAs on the router. So if an interface comes up and =
no RA is forthcoming, I could imagine the thing probing with a DHCPv6 =
request.

> Brian E Carpenter wrote:
>> Ray,
>>=20
>> On 2011-05-31 08:05, Ray Hunter wrote:
>> ...
>>  =20
>>=20
>>> Which source address (SLAAC/DHCPv6) would be used by the client for =
an
>>> outbound session if a SLAAC address and a DHCPv6 were both =
configured on
>>> the same link and with the same prefix, in the absence of a flag?=20
>>>    =20
>>>=20
>>=20
>> Whichever RFC3484bis or the local policy table determines;
>> this is orthogonal to the question of where the addresses come from.
>>=20
>>  =20
>>=20
> Hmm. That's the conclusion I also came to myself already if there were =
no flags.
>=20
> So how would you prefer DHCPv6 (centrally) assigned addresses as =
opposed to SLAAC EUI64 addresses derived from MAC BIA ?
>=20
> Is this still an open issue, and I should just be patient?
>=20
> Would you have to set a prefix for every single DHCP range in RFC3484, =
and make sure the DHCPv6 assigned range did not overlap with likely =
EUI64 derived addresses to be able to guarantee that the DHCPv6 assigned =
address will be preferred?
>=20
> Or would you have to double the amount of entries in the ACL for both =
the DHCPv6 address and the SLAAC address (coded to MAC address)
>=20
> Or will RFC3484 bis be updated to include this behavior by =
automatically guessing which addresses are SLAAC addresses and which are =
DHCPv6 addresses and allow users to prefer DHCPv6 addresses?=20
>=20
> Bearing in mind destination address selection is also affected, so it =
might have to be able to remotely 'guess' what is a SLAAC address versus =
a DHCPv6 assigned address. [I checked the RFC 3484 bis list and there is =
no text today in version 02 =
http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02 nor =
anything proposed to cover this case in emails]
>=20
> see http://www.ietf.org/mail-archive/web/ipv6/current/msg13878.html =
for the last note.
>=20
> > I'll send a query to the ipv6-ops list just to see if this is a =
common expectation.
>=20
> The answer to the operational question: Yes IMHO there is a very clear =
operational expectation of being able to easily achieve DHCPv4 like =
behavior using DHCPv6, and this is hot operational topic.
>=20
> Some people have 50000 rules in their firewalls today. They won't =
thank anyone for 100K rules (to support both SLAAC+DHCPv6), or 50K rules =
that may change every time a NIC card fails (SLAAC only).
>=20
>=20
>>> Think
>>> dynamic DNS too: which (destination) address(es) would be auto
>>> registered at the server end?
>>>    =20
>>>=20
>>=20
>> Both, if it's a server and you've chosen to use dynamic address
>> allocation for servers. Again, this is orthogonal to where
>> the addresses come from. It's going to be SOP for servers with
>> multiple addresses.
>>=20
>>  =20
>>=20
> 
>>=20
>> Yes, there are lots of bad habits that have grown up over the years
>> that IPv6 challenges. For example, setting the DSCP *as a function of
>> the source address* makes me cringe. We're going to have to get used =
to
>> the fact that IP addresses are not constants.
>>=20
>>     Brian
>>=20
>>  =20
>>=20
> In the meantime, we have to continue to operate networks whilst =
transitioning.
>=20
> As I asked, regardless of whether we think it's good or bad practice, =
I can assure you that it's certainly _common_ practice. Pretty much =
everyone I know who implements MPLS DSCP based QoS networks does it via =
IP based ACL's to overwrite DSCP on network ingress.
>=20
> offtopic: on the longer term, please give us some alternatives to =
manage and signal identities and QoS policies that are widely =
implemented by all manufacturers and all network providers. No 2 MPLS =
networks I know of use the same DSCP settings. Applications generally =
only set DSCP=3D EF on voice traffic. Everything else you have no =
standard signaling mechanism. It's rare for two OS'es to behave exactly =
the same way today. Same with 2 applications. In the absence of anything =
better, people get stuck on the lowest common denominator (IP address) =
and network ingress re-writing.
>=20
> Anyway for some operations it really isn't so bad: think of a few =
traveling VIP users who need a bit better service without spending a =
fortune on 802.1X or additional fancy multi-SSID wireless VLANs. Think =
well managed server farm and private network where there's a bulk back =
up server (all traffic placed in D3 class) next to an interactive =
software licence in server (all traffic placed in D1 class) and the rest =
of the traffic in D2. These guys are sometimes more worried about pure =
performance and cost and ease of management, rather than theft of =
service, re-writing apps etc. etc.
>=20
> Not necessarily nice. But operational reality.
>=20
> regards,
> RayH
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From hanauska@equinux.de  Tue May 31 02:12:16 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 748A9E076F for ; Tue, 31 May 2011 02:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 97AiH50NE2Sk for ; Tue, 31 May 2011 02:12:16 -0700 (PDT)
Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by ietfa.amsl.com (Postfix) with ESMTP id C6007E074A for ; Tue, 31 May 2011 02:12:15 -0700 (PDT)
Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hsidjs0171s6 for ; Tue, 31 May 2011 09:39:40 +0200 (envelope-from )
Received: from mail.muc.equinux.net ([192.168.40.207]) by mail.equinux.net (equinux Secure mail Relay) with ESMTP; Tue, 31 May 2011 09:39:40 +0200
Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id DC00221C8343; Tue, 31 May 2011 11:12:13 +0200 (CEST)
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Markus Hanauska 
In-Reply-To: 
Date: Tue, 31 May 2011 11:12:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de> 
To: Philip Homburg 
X-Mailer: Apple Mail (2.1084)
X-Mlf-Version: 7.2.1.2841
X-Mlf-UniqueId: o201105310739400080272
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: Tue, 31 May 2011 09:12:16 -0000

On 2011-05-30, at 22:27 , Philip Homburg wrote:=20

> If you are really worried about this, then I guess you can also just =
assign
> two prefixes to a single link and use one for SLAAC and the other for =
DHCPv6.

Of course this is possible, but this also means, that a node not doing =
DHCPv6 (because it does not support it or because it is disabled on the =
node), will only get an address of the SLAAC prefix and thus has to go =
to through the network router to have its packets routed the other one. =
So even though both nodes are on the same physical network, all traffic =
has to pass through a router, instead of being exchanged directly =
between the two nodes. This means a lot of unnecessary load for the this =
router to route "local traffic".

Regards,
Markus=

From pch-b2B3A6689@u-1.phicoh.com  Tue May 31 02:20: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 91954E0707 for ; Tue, 31 May 2011 02:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.369
X-Spam-Level: 
X-Spam-Status: No, score=-8.369 tagged_above=-999 required=5 tests=[AWL=0.230,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
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 9B4slCtxYk+C for ; Tue, 31 May 2011 02:20:05 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8F550E076F for ; Tue, 31 May 2011 02:20:03 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QRL7I-0001h2C; Tue, 31 May 2011 11:20:00 +0200
Message-Id: 
To: Markus Hanauska 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de> 
In-reply-to: Your message of "Tue, 31 May 2011 11:12:13 +0200 ." <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de> 
Date: Tue, 31 May 2011 11:19:59 +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: Tue, 31 May 2011 09:20:05 -0000

In your letter dated Tue, 31 May 2011 11:12:13 +0200 you wrote:
>Of course this is possible, but this also means, that a node not doing =
>DHCPv6 (because it does not support it or because it is disabled on the =
>node), will only get an address of the SLAAC prefix and thus has to go =
>to through the network router to have its packets routed the other one. =
>So even though both nodes are on the same physical network, all traffic =
>has to pass through a router, instead of being exchanged directly =
>between the two nodes. This means a lot of unnecessary load for the this =
>router to route "local traffic".

No, ND is more clever than that. All traffic between prefixes that are on-link
goes directly between the hosts. Even when the prefix is off-link it is
possible for the router the send a redirect ICMP to cause further traffic
to be directly between the hosts.



From mohacsi@niif.hu  Tue May 31 02:21:10 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 89AF3E0817 for ; Tue, 31 May 2011 02:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level: 
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245]
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 q8cxJlFoeF+M for ; Tue, 31 May 2011 02:21:10 -0700 (PDT)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id B7E5CE0736 for ; Tue, 31 May 2011 02:21:09 -0700 (PDT)
Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 9B69C874F7; Tue, 31 May 2011 11:21:07 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu
Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id pk2k9vEGHoAE; Tue, 31 May 2011 11:21:05 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 66061874DF; Tue, 31 May 2011 11:21:05 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 6388F874CF; Tue, 31 May 2011 11:21:05 +0200 (CEST)
Date: Tue, 31 May 2011 11:21:05 +0200 (CEST)
From: Mohacsi Janos 
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Markus Hanauska 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
In-Reply-To: <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>
Message-ID: 
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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: Tue, 31 May 2011 09:21:10 -0000

On Tue, 31 May 2011, Markus Hanauska wrote:

>
> On 2011-05-30, at 22:27 , Philip Homburg wrote:
>
>> If you are really worried about this, then I guess you can also just assign
>> two prefixes to a single link and use one for SLAAC and the other for DHCPv6.
>
> Of course this is possible, but this also means, that a node not doing 
> DHCPv6 (because it does not support it or because it is disabled on the 
> node), will only get an address of the SLAAC prefix and thus has to go 
> to through the network router to have its packets routed the other one. 
> So even though both nodes are on the same physical network, all traffic 
> has to pass through a router, instead of being exchanged directly 
> between the two nodes. This means a lot of unnecessary load for the this 
> router to route "local traffic".

Why would you do assign different prefixes via SLAAC and DHCPv6?

This is similar to the problem of IPv4 when you configured secondary 
addresses (from different subnet) to an interface.

Best Regards,
 		Janos Mohacsi

From mohacsi@niif.hu  Tue May 31 02:24: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 2070EE074A for ; Tue, 31 May 2011 02:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level: 
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245]
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 bv0GhL5tmuAP for ; Tue, 31 May 2011 02:24:26 -0700 (PDT)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 51595E06E5 for ; Tue, 31 May 2011 02:24:26 -0700 (PDT)
Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 5EEE3874CD; Tue, 31 May 2011 11:24:24 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu
Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id 7w5f9TUSLYu6; Tue, 31 May 2011 11:24:21 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id C165B874DF; Tue, 31 May 2011 11:24:21 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id BF97E874DA; Tue, 31 May 2011 11:24:21 +0200 (CEST)
Date: Tue, 31 May 2011 11:24:21 +0200 (CEST)
From: Mohacsi Janos 
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Markus Hanauska 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
In-Reply-To: 
Message-ID: 
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de> 
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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: Tue, 31 May 2011 09:24:27 -0000

On Tue, 31 May 2011, Mohacsi Janos wrote:

>
>
>
> On Tue, 31 May 2011, Markus Hanauska wrote:
>
>> 
>> On 2011-05-30, at 22:27 , Philip Homburg wrote:
>> 
>>> If you are really worried about this, then I guess you can also just 
>>> assign
>>> two prefixes to a single link and use one for SLAAC and the other for 
>>> DHCPv6.
>> 
>> Of course this is possible, but this also means, that a node not doing 
>> DHCPv6 (because it does not support it or because it is disabled on the 
>> node), will only get an address of the SLAAC prefix and thus has to go to 
>> through the network router to have its packets routed the other one. So 
>> even though both nodes are on the same physical network, all traffic has to 
>> pass through a router, instead of being exchanged directly between the two 
>> nodes. This means a lot of unnecessary load for the this router to route 
>> "local traffic".
>
> Why would you do assign different prefixes via SLAAC and DHCPv6?
>
> This is similar to the problem of IPv4 when you configured secondary 
> addresses (from different subnet) to an interface.


Yes, Philip is right. I was wrong.

>
> Best Regards,
> 		Janos Mohacsi
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

From hanauska@equinux.de  Tue May 31 02:29: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 CB119E07ED for ; Tue, 31 May 2011 02:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 JlsQfrEqFKhY for ; Tue, 31 May 2011 02:29:50 -0700 (PDT)
Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by ietfa.amsl.com (Postfix) with ESMTP id ECF4CE076F for ; Tue, 31 May 2011 02:29:49 -0700 (PDT)
Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hsiflo0171s6 for ; Tue, 31 May 2011 09:57:15 +0200 (envelope-from )
Received: from mail.muc.equinux.net ([192.168.40.207]) by mail.equinux.net (equinux Secure mail Relay) with ESMTP; Tue, 31 May 2011 09:57:15 +0200
Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id 40F2221C86C3; Tue, 31 May 2011 11:29:49 +0200 (CEST)
Subject: Re: [ipv6] Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Markus Hanauska 
In-Reply-To: <4DE3F87A.5060502@globis.net>
Date: Tue, 31 May 2011 11:29:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4DE3F87A.5060502@globis.net>
To: Ray Hunter 
X-Mailer: Apple Mail (2.1084)
X-Mlf-Version: 7.2.1.2841
X-Mlf-UniqueId: o201105310757150080408
Cc: Thomas Narten , ipv6@ietf.org, Ralph Droms 
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, 31 May 2011 09:29:50 -0000

On 2011-05-30, at 22:05 , Ray Hunter wrote:

> Which source address (SLAAC/DHCPv6) would be used by the client for an =
outbound session if a SLAAC address and a DHCPv6 were both configured on =
the same link and with the same prefix, in the absence of a flag?

As I already said in my previous mail: The DHCP address should win by =
default; that is, of course, unless the admin/user of the node has =
configured anything else. If a network runs a DHCP server that hands out =
addresses, network admins probably do so for a reason. The SLAAC one is =
valid and inbound traffic might arrive for it, but for outgoing traffic, =
some RFC should simply have given an order of preference:

1. Manual configured IP
2. DHCP
3. SLAAC with Privacy Extension
4. SLAAC with Interface ID

>  Think dynamic DNS too: which (destination) address(es) would be auto =
registered at the server end?

All of them, since a single DNS entry can resolve to plenty of different =
IP addresses (DNS has always been designed to allow this scenario). The =
order should be the same as the order of preference above, though you =
can argue if it is meaningful to register Privacy Extension addresses at =
all, since they will dynamically change pretty often.

> There are a lot of operational people who currently rely on having =
predictable IP addresses for accounting, audit, scripting, firewall =
rules, neighbor filtering, fault tracing, reverse DNS, policy based =
routing, setting DSCP in QoS, any other number of ACL's  ....

I can also totally agree with your statement above - but there is one =
thing you are missing: It is not only important, to have predictable IP =
addresses in some scenarios, it is also important to have "constant" IP =
addresses, since even if the address is predictable, it will be a =
problem if it is going to change every couple of months. SLAAC addresses =
based on interface IP are in fact predictable; but they not constant! On =
the other hand, when using DHCP, it takes me 2 minutes to change the =
stored interface ID of a DHCP client in the server config to assure, =
that even after an interface ID change, the client still gets the same =
IP address as before. How will you do this with SLAAC? Manually =
configuring the same MAC address as the old interface? You shouldn't =
manually assign MAC addresses, if not really necessary, especially not =
those which claim to be globally unique, even though they are in fact =
not. MAC address collisions are worst case scenarios for most networks. =
Further certain clients, e.g. take an iPhone or iPad, don't allow you to =
change interface IDs at all AFAIK.

Regards,
Markus=

From hanauska@equinux.de  Tue May 31 02:54:59 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 8AF70E074A for ; Tue, 31 May 2011 02:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 Sl-3u0GINmWO for ; Tue, 31 May 2011 02:54:59 -0700 (PDT)
Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by ietfa.amsl.com (Postfix) with ESMTP id C0545E06D8 for ; Tue, 31 May 2011 02:54:58 -0700 (PDT)
Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hsiik00171s2 for ; Tue, 31 May 2011 10:22:23 +0200 (envelope-from )
Received: from mail.muc.equinux.net ([192.168.40.207]) by mail.equinux.net (equinux Secure mail Relay) with ESMTP; Tue, 31 May 2011 10:22:23 +0200
Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id 5059D21C8BB7; Tue, 31 May 2011 11:54:57 +0200 (CEST)
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Markus Hanauska 
In-Reply-To: 
Date: Tue, 31 May 2011 11:54:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de>
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de> 
To: Philip Homburg 
X-Mailer: Apple Mail (2.1084)
X-Mlf-Version: 7.2.1.2841
X-Mlf-UniqueId: o201105310822230080596
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: Tue, 31 May 2011 09:54:59 -0000

On 2011-05-31, at 11:19 , Philip Homburg wrote:

> No, ND is more clever than that. All traffic between prefixes that are =
on-link
> goes directly between the hosts. Even when the prefix is off-link it =
is
> possible for the router the send a redirect ICMP to cause further =
traffic
> to be directly between the hosts.

I don't think this related to ND, is it? ICMP redirects also exist for =
IPv4 and IPv4 doesn't know ND. I think only difference is that ICPMv6 =
optionally allows an link layer address in the redirect message. How =
good IPv6 implementations really support ICMPv6 redirects as of today is =
another question.

My main problem with that approach is, that not everyone has a $5000++ =
Cisco router available and the configuration capabilities of some more =
inexpensive routers are quite limited; especially regarding IPv6, which =
is still not mainstream (the majority of routers on the market still has =
no IPv6 support at all). Also what are you going to do, if your ISP only =
gives you a single /64 prefix? To subdivide it, you have to use some =
bits for subnetworking, which means your hosts might only have /48 =
addresses and that disables SLAAC entirely.

I still think it would have been much easier, to define a second bit in =
the /64 address space. Just like the 'u' bit, which says that an address =
is globally unique or not, there would be the 'a' bit, which is set if =
the address has been assigned "automatically" (SLAAC w/ or w/o Privacy =
Extension) and not set, if this address has been "manually" assigned =
(either by manual config on the node or by DHCP or anything comparable =
to DHCP). This will effectively eliminate collisions, except for MAC =
address collisions or collisions caused by misconfiguration of manual =
IPs and/or DHCP.

Regards,
Markus=

From mohacsi@niif.hu  Tue May 31 02:57:25 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 23F35E076E for ; Tue, 31 May 2011 02:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level: 
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245]
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 VHUkfrEVp7Vn for ; Tue, 31 May 2011 02:57:24 -0700 (PDT)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 393A1E06DE for ; Tue, 31 May 2011 02:57:24 -0700 (PDT)
Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 4A70B874DA; Tue, 31 May 2011 11:57:22 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu
Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id t2jugiVnfg1M; Tue, 31 May 2011 11:57:19 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 916A3874EC; Tue, 31 May 2011 11:57:19 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 8FD5B874E3; Tue, 31 May 2011 11:57:19 +0200 (CEST)
Date: Tue, 31 May 2011 11:57:19 +0200 (CEST)
From: Mohacsi Janos 
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Markus Hanauska 
Subject: Re: [ipv6] Node Requirements: Elevating DHCPv6 from MAY to SHOULD
In-Reply-To: 
Message-ID: 
References: <4DE3F87A.5060502@globis.net> 
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Thomas Narten , Ray Hunter , ipv6@ietf.org, Ralph Droms 
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, 31 May 2011 09:57:25 -0000

On Tue, 31 May 2011, Markus Hanauska wrote:

>
> On 2011-05-30, at 22:05 , Ray Hunter wrote:
>
>> Which source address (SLAAC/DHCPv6) would be used by the client for an 
>> outbound session if a SLAAC address and a DHCPv6 were both configured 
>> on the same link and with the same prefix, in the absence of a flag?
>
> As I already said in my previous mail: The DHCP address should win by 
> default; that is, of course, unless the admin/user of the node has 
> configured anything else. If a network runs a DHCP server that hands out 
> addresses, network admins probably do so for a reason. The SLAAC one is 
> valid and inbound traffic might arrive for it, but for outgoing traffic, 
> some RFC should simply have given an order of preference:
>
> 1. Manual configured IP
> 2. DHCP
> 3. SLAAC with Privacy Extension
> 4. SLAAC with Interface ID

I don't see the exact argument behind this ordering.

What about the ordering, if you get more than one DHCP addresses?

>From operating system point of view all the addresses are the same. How do 
you select which one to use? The RFC 4941 states, that usage of Privacy 
enhanced addresses can be selected based on the destination addresses.

If you want consistent behaviour, the application should bind() to a 
specific address.


>
>> There are a lot of operational people who currently rely on having 
>> predictable IP addresses for accounting, audit, scripting, firewall 
>> rules, neighbor filtering, fault tracing, reverse DNS, policy based 
>> routing, setting DSCP in QoS, any other number of ACL's ....
>
> I can also totally agree with your statement above - but there is one 
> thing you are missing: It is not only important, to have predictable IP 
> addresses in some scenarios, it is also important to have "constant" IP 
> addresses, since even if the address is predictable, it will be a 
> problem if it is going to change every couple of months. SLAAC addresses 
> based on interface IP are in fact predictable; but they not constant! On 
> the other hand, when using DHCP, it takes me 2 minutes to change the 
> stored interface ID of a DHCP client in the server config to assure, 
> that even after an interface ID change, the client still gets the same 
> IP address as before. How will you do this with SLAAC?

Not with SLAAC, but static addresses. Anyway usually the requirement is 
not the "constant" IP, but accountability of the user/server.

Best Regards,
 		Janos Mohacsi


From mohacsi@niif.hu  Tue May 31 03:10: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 9EDE5E076F for ; Tue, 31 May 2011 03:10:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level: 
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245]
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 08C4ifq8nzv1 for ; Tue, 31 May 2011 03:10:16 -0700 (PDT)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA72E06C2 for ; Tue, 31 May 2011 03:10:16 -0700 (PDT)
Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 5E834874E7; Tue, 31 May 2011 12:10:14 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu
Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id 8aqWVpQsL0Om; Tue, 31 May 2011 12:10:11 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 3600E874D3; Tue, 31 May 2011 12:10:11 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 30688874CF; Tue, 31 May 2011 12:10:11 +0200 (CEST)
Date: Tue, 31 May 2011 12:10:11 +0200 (CEST)
From: Mohacsi Janos 
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Markus Hanauska 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
In-Reply-To: <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de>
Message-ID: 
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>  <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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: Tue, 31 May 2011 10:10:17 -0000

On Tue, 31 May 2011, Markus Hanauska wrote:

>
> On 2011-05-31, at 11:19 , Philip Homburg wrote:
>
>
> My main problem with that approach is, that not everyone has a $5000++ 
> Cisco router available and the configuration capabilities of some more 
> inexpensive routers are quite limited; especially regarding IPv6, which 
> is still not mainstream (the majority of routers on the market still has 
> no IPv6 support at all). Also what are you going to do, if your ISP only 
> gives you a single /64 prefix? To subdivide it, you have to use some 
> bits for subnetworking, which means your hosts might only have /48 
> addresses and that disables SLAAC entirely.

If you get /64 and you need more subnets from your provider then probably 
you asked something wrong.
You should get /64 if and only if you have only one subnet! Or your ISP 
does not understand IPv6. In this case avoid it.

>
> I still think it would have been much easier, to define a second bit in 
> the /64 address space. Just like the 'u' bit, which says that an address 
> is globally unique or not, there would be the 'a' bit, which is set if 
> the address has been assigned "automatically" (SLAAC w/ or w/o Privacy 
> Extension) and not set, if this address has been "manually" assigned 
> (either by manual config on the node or by DHCP or anything comparable 
> to DHCP). This will effectively eliminate collisions, except for MAC 
> address collisions or collisions caused by misconfiguration of manual 
> IPs and/or DHCP.
>

What collision? You should use 'u' bit accrdingly:
1 - if automaticaly assigned
0 - if manually assigned.

Best Regards,
 		Janos Mohacsi

From swmike@swm.pp.se  Tue May 31 03:28: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 0DDC3E06B9 for ; Tue, 31 May 2011 03:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 lIeghMvTyNlF for ; Tue, 31 May 2011 03:28:07 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id E2A6DE06AE for ; Tue, 31 May 2011 03:28:06 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 538D59C; Tue, 31 May 2011 12:28:01 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 514B09A; Tue, 31 May 2011 12:28:01 +0200 (CEST)
Date: Tue, 31 May 2011 12:28:01 +0200 (CEST)
From: Mikael Abrahamsson 
To: Philip Homburg 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
In-Reply-To: 
Message-ID: 
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de> 
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
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: Tue, 31 May 2011 10:28:08 -0000

On Tue, 31 May 2011, Philip Homburg wrote:

> No, ND is more clever than that. All traffic between prefixes that are 
> on-link goes directly between the hosts. Even when the prefix is 
> off-link it is possible for the router the send a redirect ICMP to cause 
> further traffic to be directly between the hosts.

I hope there is a recommendation in the standard to have a knob to turn 
this off? With security functions like forced-forwarding and alike, I'd 
definitely not want the hosts to try to communicate directly between each 
other.

I was under the impression that if I don't announce an on-link prefix at 
all, and just do DHCPv6, there hosts would not try to communicate with 
each other directly (ie there is no routing to support this function). 
You're saying my presumption is not true?

Why would a host try to do ND for something that is not on-link according 
to its routing table?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From pch-b2B3A6689@u-1.phicoh.com  Tue May 31 03:35:04 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 90D4DE0784 for ; Tue, 31 May 2011 03:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.407
X-Spam-Level: 
X-Spam-Status: No, score=-8.407 tagged_above=-999 required=5 tests=[AWL=0.192,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
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 p8cRb8m3+QG1 for ; Tue, 31 May 2011 03:35:04 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id C8870E06AE for ; Tue, 31 May 2011 03:35:03 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QRMHt-0001h3C; Tue, 31 May 2011 12:35:01 +0200
Message-Id: 
To: Markus Hanauska 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>  <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de> 
In-reply-to: Your message of "Tue, 31 May 2011 11:54:57 +0200 ." <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de> 
Date: Tue, 31 May 2011 12:35:01 +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: Tue, 31 May 2011 10:35:04 -0000

In your letter dated Tue, 31 May 2011 11:54:57 +0200 you wrote:
>I don't think this related to ND, is it? ICMP redirects also exist for =
>IPv4 and IPv4 doesn't know ND. I think only difference is that ICPMv6 =
>optionally allows an link layer address in the redirect message. How =
>good IPv6 implementations really support ICMPv6 redirects as of today is =
>another question.

The difference is that IPv4 has a model of one subnet per link. If you
get an ICMP for something that is not on your subnet, then it is best to 
ignore it. There is no problem get the link layer address: just ARP for it.

>My main problem with that approach is, that not everyone has a $5000++ =
>Cisco router available and the configuration capabilities of some more =
>inexpensive routers are quite limited; especially regarding IPv6, which =
>is still not mainstream (the majority of routers on the market still has =
>no IPv6 support at all). 

That's always that case if you want a configuration that is not mainstream:
you either have to buy a more expensive product that has more configuration
options or, in many cases, you can also use open source.



From hanauska@equinux.de  Tue May 31 03:37: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 EF239E076F for ; Tue, 31 May 2011 03:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 b65ZWnexPVUB for ; Tue, 31 May 2011 03:37:06 -0700 (PDT)
Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by ietfa.amsl.com (Postfix) with ESMTP id 456BAE06AE for ; Tue, 31 May 2011 03:37:06 -0700 (PDT)
Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hsini00171s1 for ; Tue, 31 May 2011 11:04:31 +0200 (envelope-from )
Received: from mail.muc.equinux.net ([192.168.40.207]) by mail.equinux.net (equinux Secure mail Relay) with ESMTP; Tue, 31 May 2011 11:04:30 +0200
Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id 4264221C935F; Tue, 31 May 2011 12:37:05 +0200 (CEST)
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Markus Hanauska 
In-Reply-To: 
Date: Tue, 31 May 2011 12:37:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <805C1C3B-616E-4B2C-8774-5890E79BA13B@equinux.de>
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>  <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de> 
To: Mohacsi Janos 
X-Mailer: Apple Mail (2.1084)
X-Mlf-Version: 7.2.1.2841
X-Mlf-UniqueId: o201105310904300080942
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: Tue, 31 May 2011 10:37:07 -0000

On 2011-05-31, at 12:10 , Mohacsi Janos wrote:

> If you get /64 and you need more subnets from your provider then =
probably you asked something wrong.

Or you have the wrong provider... but if this is the only provider =
available in your area, that can offer you a symmetric 100 MBit/s fibre =
connection for business purposes, what are you going to do? Move your =
whole company elsewhere? I don't think so. Sometimes it is also a =
question of money; you can have a larger prefix, if you are willing to =
pay ten times the price, which is not acceptable for every company in =
the world.

> What collision? You should use 'u' bit accrdingly:
> 1 - if automaticaly assigned
> 0 - if manually assigned.

But it is also 0 for SLAAC addresses w/ privacy extension and those are =
automatically assigned, in example.

Regards,
Markus=

From pch-b2B3A6689@u-1.phicoh.com  Tue May 31 03:40: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 245A4E0784 for ; Tue, 31 May 2011 03:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.435
X-Spam-Level: 
X-Spam-Status: No, score=-8.435 tagged_above=-999 required=5 tests=[AWL=0.164,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
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 g2qbeZGjvWqK for ; Tue, 31 May 2011 03:40:35 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id CCD82E076F for ; Tue, 31 May 2011 03:40:34 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QRMNF-0001ipC; Tue, 31 May 2011 12:40:33 +0200
Message-Id: 
To: Mikael Abrahamsson 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>   
In-reply-to: Your message of "Tue, 31 May 2011 12:28:01 +0200 (CEST) ."  
Date: Tue, 31 May 2011 12:40:32 +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: Tue, 31 May 2011 10:40:39 -0000

In your letter dated Tue, 31 May 2011 12:28:01 +0200 (CEST) you wrote:
>On Tue, 31 May 2011, Philip Homburg wrote:
>> No, ND is more clever than that. All traffic between prefixes that are 
>> on-link goes directly between the hosts. Even when the prefix is 
>> off-link it is possible for the router the send a redirect ICMP to cause 
>> further traffic to be directly between the hosts.
>
>I hope there is a recommendation in the standard to have a knob to turn 
>this off? With security functions like forced-forwarding and alike, I'd 
>definitely not want the hosts to try to communicate directly between each 
>other.

A prefix only becomes on-link if there is a prefix option that says so.

Of course, absent secure ND, any host can fake a redirect ICMP. So you either
SEND or L2 devices that filter ICMPs. But you need that anyhow.

>I was under the impression that if I don't announce an on-link prefix at 
>all, and just do DHCPv6, there hosts would not try to communicate with 
>each other directly (ie there is no routing to support this function). 
>You're saying my presumption is not true?

If the prefix is not announced as on-link then hosts have to send their
packets to a default router until they get a redirect.

>Why would a host try to do ND for something that is not on-link according 
>to its routing table?

I was not implying that hosts would that without a router announcing the 
prefix as on-link. I just wanted to make clear that IPv6 *supports* direct
communication between hosts that use addresses from different prefixes.



From pch-b2B3A6689@u-1.phicoh.com  Tue May 31 03:46:31 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 F3154E076F for ; Tue, 31 May 2011 03:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.455
X-Spam-Level: 
X-Spam-Status: No, score=-8.455 tagged_above=-999 required=5 tests=[AWL=0.144,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
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 Cho94ZLuF7Eb for ; Tue, 31 May 2011 03:46:30 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 38DECE0797 for ; Tue, 31 May 2011 03:46:30 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QRMSy-0001h8C; Tue, 31 May 2011 12:46:28 +0200
Message-Id: 
To: Markus Hanauska 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>  <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de>  <805C1C3B-616E-4B2C-8774-5890E79BA13B@equinux.de> 
In-reply-to: Your message of "Tue, 31 May 2011 12:37:05 +0200 ." <805C1C3B-616E-4B2C-8774-5890E79BA13B@equinux.de> 
Date: Tue, 31 May 2011 12:46:28 +0200
Cc: "ipv6@ietf.org" , Mohacsi Janos 
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, 31 May 2011 10:46:31 -0000

In your letter dated Tue, 31 May 2011 12:37:05 +0200 you wrote:
>Or you have the wrong provider... but if this is the only provider =
>available in your area, that can offer you a symmetric 100 MBit/s fibre =
>connection for business purposes, what are you going to do? Move your =
>whole company elsewhere? I don't think so. Sometimes it is also a =
>question of money; you can have a larger prefix, if you are willing to =
>pay ten times the price, which is not acceptable for every company in =
>the world.

If the only provider available doesn't do IPv6 at all, then what do you do?
If you want a separate guest net for wifi and you only get one a /64, then
what do you do?

You can't engineer protocols around providers that want to make their
customers misserable.

There are plenty of /48s for everybody. Let's use them!



From swmike@swm.pp.se  Tue May 31 04:06:24 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 9DA5AE06AE for ; Tue, 31 May 2011 04:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 3aEgKvFPoLfM for ; Tue, 31 May 2011 04:06:23 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id B6578E070A for ; Tue, 31 May 2011 04:06:22 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0F2F79E; Tue, 31 May 2011 13:06:20 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0C14E9C; Tue, 31 May 2011 13:06:20 +0200 (CEST)
Date: Tue, 31 May 2011 13:06:20 +0200 (CEST)
From: Mikael Abrahamsson 
To: Philip Homburg 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
In-Reply-To: 
Message-ID: 
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>   
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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: Tue, 31 May 2011 11:06:24 -0000

On Tue, 31 May 2011, Philip Homburg wrote:

>> I hope there is a recommendation in the standard to have a knob to turn
>> this off? With security functions like forced-forwarding and alike, I'd
>> definitely not want the hosts to try to communicate directly between each
>> other.
>
> A prefix only becomes on-link if there is a prefix option that says so.

Hm, I might not understand what you mean by "prefix option" here, if an 
ICMP-redirect all of a sudden can make a /128 be on-link even though it's 
not in my routing table.

> I was not implying that hosts would that without a router announcing the 
> prefix as on-link. I just wanted to make clear that IPv6 *supports* 
> direct communication between hosts that use addresses from different 
> prefixes.

Absolutely, but if there is another way than to announce the on-link 
prefix than might make hosts communicate directly to each other on a 
subnet, that's news to me and I find this extremely interesting from a 
security standpoint.

For me, if I have:

R1 X::1/64
H2 X::2/128
H3 X::3/128

R1 doesn't announce any on-link prefix, so H2 and H3 use R1 to communicate 
between each other (they just have their own /128 in their routing table 
and default route pointing to R1 LL address learnt via RA).

Now, what I interpreted you saying is that R1 can tell H2 that H3 is 
on-link by means of an ICMP redirect. This has security (and functional) 
implications in that any L2 network they might have that disallows H2 and 
H3 to communicate between each other even though they're in the same vlan, 
will make this completely stop working if R1 doesn't have a knob to 
disallow it from sending redirects that might indicate that H2 and H3 is 
on the same L2 domain (on-link).

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From mohacsi@niif.hu  Tue May 31 04:10:07 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 33B89E0825 for ; Tue, 31 May 2011 04:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level: 
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245]
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 xkYcWqL2TEyn for ; Tue, 31 May 2011 04:10:02 -0700 (PDT)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 52743E07A1 for ; Tue, 31 May 2011 04:10:02 -0700 (PDT)
Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id CFE7F87503; Tue, 31 May 2011 13:10:00 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu
Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id krRIMbWvoEcK; Tue, 31 May 2011 13:09:56 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id EFDDD874E5; Tue, 31 May 2011 13:09:55 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id EB452874CD; Tue, 31 May 2011 13:09:55 +0200 (CEST)
Date: Tue, 31 May 2011 13:09:55 +0200 (CEST)
From: Mohacsi Janos 
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Markus Hanauska 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
In-Reply-To: <805C1C3B-616E-4B2C-8774-5890E79BA13B@equinux.de>
Message-ID: 
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>  <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de>  <805C1C3B-616E-4B2C-8774-5890E79BA13B@equinux.de>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
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: Tue, 31 May 2011 11:10:07 -0000

On Tue, 31 May 2011, Markus Hanauska wrote:

>
> On 2011-05-31, at 12:10 , Mohacsi Janos wrote:
>
>> If you get /64 and you need more subnets from your provider then probably you asked something wrong.
>
> Or you have the wrong provider...

I agree.

> but if this is the only provider 
> available in your area, that can offer you a symmetric 100 MBit/s fibre 
> connection for business purposes, what are you going to do? Move your 
> whole company elsewhere? I don't think so. Sometimes it is also a 
> question of money; you can have a larger prefix, if you are willing to 
> pay ten times the price, which is not acceptable for every company in 
> the world.

You have to explain your provider to assign more otherwise they are not 
following the registration policy documents of RIRs e.g Section 5.3 
and 5.4.x
http://www.ripe.net/ripe/docs/ripe-512


>
>> What collision? You should use 'u' bit accrdingly:
>> 1 - if automaticaly assigned
>> 0 - if manually assigned.
>
> But it is also 0 for SLAAC addresses w/ privacy extension and those are automatically assigned, in example.


You can argument for change in the RFC 4941 revision.

Best Regards,
 		Janos Mohacsi

From hanauska@equinux.de  Tue May 31 04:19: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 C417AE0692 for ; Tue, 31 May 2011 04:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 fJy1kEhZI97Q for ; Tue, 31 May 2011 04:19:41 -0700 (PDT)
Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by ietfa.amsl.com (Postfix) with ESMTP id BDE92E0670 for ; Tue, 31 May 2011 04:19:40 -0700 (PDT)
Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hsishk0171st for ; Tue, 31 May 2011 11:47:04 +0200 (envelope-from )
Received: from mail.muc.equinux.net ([192.168.40.207]) by mail.equinux.net (equinux Secure mail Relay) with ESMTP; Tue, 31 May 2011 11:47:04 +0200
Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id 524A121C9A3E; Tue, 31 May 2011 13:19:39 +0200 (CEST)
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Markus Hanauska 
In-Reply-To: 
Date: Tue, 31 May 2011 13:19:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <568E4F89-520A-4362-B0FA-7B64A5B82139@equinux.de>
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>  <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de> 
To: Philip Homburg 
X-Mailer: Apple Mail (2.1084)
X-Mlf-Version: 7.2.1.2841
X-Mlf-UniqueId: o201105310947040081470
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: Tue, 31 May 2011 11:19:41 -0000

On 2011-05-31, at 12:35 , Philip Homburg wrote:

> The difference is that IPv4 has a model of one subnet per link.

Why do you think so? The computer I'm using right now has two IP =
addresses of different IP subnets on the same network interface (and I =
really mean the same layer 2 network, there are no VLANs in use). I =
think pretty much any operating system as of today allows for such a =
configuration.

> That's always that case if you want a configuration that is not =
mainstream:
> you either have to buy a more expensive product that has more =
configuration
> options or, in many cases, you can also use open source.

But don't you think it helps a lot to push a new technology to =
mainstream if it is possible to also use this technology without any =
expensive hardware or complicated configurations? My main argument was =
(and still is), that through a couple of tiny changes in the RFCs (only =
a couple of sentences) and equally small changes to implementations =
(5-10 lines of additional code), IPv6 could have been so much easier for =
everyone: Hardware vendors producing IPv6 hardware, software vendors =
writing IPv6 software, network administrators creating IPv6 networks, =
end users actually using IPv6. The negative impact would have been close =
to zero, the positive impact would have been big and maybe IPv6 would =
have been somewhat more mainstream as of today if people had considered =
some tiny things. The most important ones are:

1) A need for DHCPv6 right from the start and taking it into =
consideration everywhere SLAAC was taken into consideration. E.g. is =
this thread; DHCPv6 should have been "SHOULD" right from day one.

2) A better way to run SLAAC, SLAAC + Privacy Ext, DHCP and manual =
addressing all on the same link *AND* same prefix in such a way, that it =
is almost address conflict free without having to rely on ND to discover =
conflicts (since ND will fail for hosts currently offline, but with =
reserved addresses): Defining all addressing schemes in such a way, that =
they don't interfere with each other under "normal" operation conditions =
- of course MAC address conflicts are still possible, two nodes with =
SLAAC + Priv Ext may also collide (only ND can avoid that) and =
misconfiguration will always be possible; but I consider none of these =
as normal operation conditions). Only two flags in 64 bit node addresses =
would have been necessary for that.

3) No M/O bits in router advertise messages. Every interface can have a =
manually configured address, a DHCPv6 address, a SLAAC address, a SLAAC =
w/ Priv Ext and that for every prefix it is aware of. The order of =
preference for outgoing traffic is configurable, the default order is =
defined in any RFC (e.g. I would suggest manual, DHCP, SLAAC w/ Priv =
Ext, SLAAC).

4) Considering DNS right from the start, since DNS is almost critical =
for many networks as of today. If one of the IPv6 main design goal was =
to allow the majority of networks to operate without a DHCP server (and =
it looks as if it was, otherwise DHCPv6 would have been taken much more =
into account), something like RFC 6106 (former 5006) was missing way too =
long IMHO. Though I still fail to see the need for this RFC at all; I =
had rather said that for simple setups that don't provide DNS servers =
via DHCP, it would have been enough to have a well defined anycast or =
even multicast address for DNS servers (I don't know any real life =
network where DNS server addresses changes so frequently, that this =
wouldn't work well in practice).

Regards,
Markus=

From mohacsi@niif.hu  Tue May 31 04:38: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 1697AE06B9 for ; Tue, 31 May 2011 04:38:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level: 
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245]
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 gSLn9uhChAtO for ; Tue, 31 May 2011 04:38:35 -0700 (PDT)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id F26E1E06AE for ; Tue, 31 May 2011 04:38:33 -0700 (PDT)
Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id 01A33874E3; Tue, 31 May 2011 13:38:31 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu
Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id ZlHDCoLapyKI; Tue, 31 May 2011 13:38:28 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 1CDD487508; Tue, 31 May 2011 13:38:28 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 169AF874F8; Tue, 31 May 2011 13:38:28 +0200 (CEST)
Date: Tue, 31 May 2011 13:38:28 +0200 (CEST)
From: Mohacsi Janos 
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Markus Hanauska 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
In-Reply-To: <568E4F89-520A-4362-B0FA-7B64A5B82139@equinux.de>
Message-ID: 
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>  <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de>  <568E4F89-520A-4362-B0FA-7B64A5B82139@equinux.de>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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: Tue, 31 May 2011 11:38:36 -0000

On Tue, 31 May 2011, Markus Hanauska wrote:

>
>
> But don't you think it helps a lot to push a new technology to 
> mainstream if it is possible to also use this technology without any 
> expensive hardware or complicated configurations? My main argument was 
> (and still is), that through a couple of tiny changes in the RFCs (only 
> a couple of sentences) and equally small changes to implementations 
> (5-10 lines of additional code), IPv6 could have been so much easier for 
> everyone: Hardware vendors producing IPv6 hardware, software vendors 
> writing IPv6 software, network administrators creating IPv6 networks, 
> end users actually using IPv6. The negative impact would have been close 
> to zero, the positive impact would have been big and maybe IPv6 would 
> have been somewhat more mainstream as of today if people had considered 
> some tiny things. The most important ones are:

The impact of changes can be quite substantial.

>
> 1) A need for DHCPv6 right from the start and taking it into 
> consideration everywhere SLAAC was taken into consideration. E.g. is 
> this thread; DHCPv6 should have been "SHOULD" right from day one.


Agree. Adding DHCPv6 support to an existing IPv6 capable implementation 
might be possible.

>
> 2) A better way to run SLAAC, SLAAC + Privacy Ext, DHCP and manual 
> addressing all on the same link *AND* same prefix in such a way, that it 
> is almost address conflict free without having to rely on ND to discover 
> conflicts (since ND will fail for hosts currently offline, but with 
> reserved addresses): Defining all addressing schemes in such a way, that 
> they don't interfere with each other under "normal" operation conditions 
> - of course MAC address conflicts are still possible, two nodes with 
> SLAAC + Priv Ext may also collide (only ND can avoid that) and 
> misconfiguration will always be possible; but I consider none of these 
> as normal operation conditions). Only two flags in 64 bit node addresses 
> would have been necessary for that.

I disagree with introduction of another flags. This requires substantial 
changes in the codes.... Which will take ages....

>
> 3) No M/O bits in router advertise messages. Every interface can have a 
> manually configured address, a DHCPv6 address, a SLAAC address, a SLAAC 
> w/ Priv Ext and that for every prefix it is aware of. The order of 
> preference for outgoing traffic is configurable, the default order is 
> defined in any RFC (e.g. I would suggest manual, DHCP, SLAAC w/ Priv 
> Ext, SLAAC).

We need M/O bits to give some sort of consistency. But nothing prevent a 
host to use DHCPv6 and SLAAC address and static in the same time.

I have to disagree with your suggested ordering.

>
> 4) Considering DNS right from the start, since DNS is almost critical 
> for many networks as of today. If one of the IPv6 main design goal was 
> to allow the majority of networks to operate without a DHCP server (and 
> it looks as if it was, otherwise DHCPv6 would have been taken much more 
> into account), something like RFC 6106 (former 5006) was missing way too 
> long IMHO. Though I still fail to see the need for this RFC at all; I 
> had rather said that for simple setups that don't provide DNS servers 
> via DHCP, it would have been enough to have a well defined anycast or 
> even multicast address for DNS servers (I don't know any real life 
> network where DNS server addresses changes so frequently, that this 
> wouldn't work well in practice).

Nothing prevent you the suggest an draft document for multicast or anycast 
resolving DNS. There is environment where SLAAC more acceptable - e.g. 
less adminisration, and there is environment where DHCPv6 is the only way 
to operate.


Best Regards,
 		Janos Mohacsi

From hanauska@equinux.de  Tue May 31 04:39:18 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 91B2CE0789 for ; Tue, 31 May 2011 04:39:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 JrxbQvAB1x24 for ; Tue, 31 May 2011 04:39:16 -0700 (PDT)
Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by ietfa.amsl.com (Postfix) with ESMTP id BB525E078C for ; Tue, 31 May 2011 04:39:15 -0700 (PDT)
Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hsiur00171s1 for ; Tue, 31 May 2011 12:06:40 +0200 (envelope-from )
Received: from mail.muc.equinux.net ([192.168.40.207]) by mail.equinux.net (equinux Secure mail Relay) with ESMTP; Tue, 31 May 2011 12:06:40 +0200
Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id 0B1FB21C9AF0; Tue, 31 May 2011 13:39:15 +0200 (CEST)
Subject: Re: [ipv6] Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Markus Hanauska 
In-Reply-To: 
Date: Tue, 31 May 2011 13:39:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <98089550-58BD-48C2-84BD-7A0A9223F1B3@equinux.de>
References: <4DE3F87A.5060502@globis.net>  
To: Mohacsi Janos 
X-Mailer: Apple Mail (2.1084)
X-Mlf-Version: 7.2.1.2841
X-Mlf-UniqueId: o201105311006400081627
Cc: Thomas Narten , Ray Hunter , ipv6@ietf.org, Ralph Droms 
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, 31 May 2011 11:39:18 -0000

On 2011-05-31, at 11:57 , Mohacsi Janos wrote:

> What about the ordering, if you get more than one DHCP addresses?

How would this be any different to the situation as we have it today? =
It's rather strange arguing to say something introduces a problem, if =
this is not a new problem, but one that is in existence already by the =
current standards. In whatever way this situation is handled today, it =
would be handled the same way, I'd say.

> =46rom operating system point of view all the addresses are the same.

This is not quite true. If I have a SLAAC address with interface ID and =
one with Priv Ext, all systems I know prefer the one with Priv Ext for =
outgoing traffic, unless a client/server software explicitly picks =
another one. The same thing could be the case for DHCP addresses.

>  The RFC 4941 states, that usage of Privacy enhanced addresses can be =
selected based on the destination addresses.

Yes, but there is nothing special about this. Every address can be =
picked according to the destination address simply by adding a routing =
table entry for a certain destination or destination range; this also =
works with IPv4.

> Not with SLAAC, but static addresses.

My impression was the consent on this list is that static addresses are =
evil(TM), since it is the most error prone way of assigning addresses on =
a network. And I cannot really disagree, there is some truth in that =
statement. Also it is more painful to remotely log into hosts and =
manually assign them IPs, instead of managing all this in a central =
place: The DHCP server config.

Regards,
Markus=

From pch-b2B3A6689@u-1.phicoh.com  Tue May 31 04:39:59 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 450BBE06B9 for ; Tue, 31 May 2011 04:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.471
X-Spam-Level: 
X-Spam-Status: No, score=-8.471 tagged_above=-999 required=5 tests=[AWL=0.128,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
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 VZyxUU1EmzpK for ; Tue, 31 May 2011 04:39:58 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id DE73AE076F for ; Tue, 31 May 2011 04:39:57 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QRNIi-0001gzC; Tue, 31 May 2011 13:39:56 +0200
Message-Id: 
To: Mikael Abrahamsson 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>     
In-reply-to: Your message of "Tue, 31 May 2011 13:06:20 +0200 (CEST) ."  
Date: Tue, 31 May 2011 13:39:55 +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: Tue, 31 May 2011 11:39:59 -0000

In your letter dated Tue, 31 May 2011 13:06:20 +0200 (CEST) you wrote:
>Absolutely, but if there is another way than to announce the on-link 
>prefix than might make hosts communicate directly to each other on a 
>subnet, that's news to me and I find this extremely interesting from a 
>security standpoint.
>
>For me, if I have:
>
>R1 X::1/64
>H2 X::2/128
>H3 X::3/128
>
>R1 doesn't announce any on-link prefix, so H2 and H3 use R1 to communicate 
>between each other (they just have their own /128 in their routing table 
>and default route pointing to R1 LL address learnt via RA).
>
>Now, what I interpreted you saying is that R1 can tell H2 that H3 is 
>on-link by means of an ICMP redirect. This has security (and functional) 
>implications in that any L2 network they might have that disallows H2 and 
>H3 to communicate between each other even though they're in the same vlan, 
>will make this completely stop working if R1 doesn't have a knob to 
>disallow it from sending redirects that might indicate that H2 and H3 is 
>on the same L2 domain (on-link).

RFC-4861 (Neighbor Discovery for IP version 6 (IPv6)):
"8.3.  Host Specification
[...]
"If the Target and Destination Addresses are the same, the host MUST treat the
"Target as on-link.

I have no idea why you want hosts on the same vlan and then use L2 filtering
to prevent them from communicating directly. But yes, if the router would
then start sending redirects, it would create a mess.



From hanauska@equinux.de  Tue May 31 04:43:21 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 7444FE079C for ; Tue, 31 May 2011 04:43:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 YhyrpeWMCPsH for ; Tue, 31 May 2011 04:43:20 -0700 (PDT)
Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by ietfa.amsl.com (Postfix) with ESMTP id B956FE0708 for ; Tue, 31 May 2011 04:43:20 -0700 (PDT)
Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hsivaa0171sr for ; Tue, 31 May 2011 12:10:45 +0200 (envelope-from )
Received: from mail.muc.equinux.net ([192.168.40.207]) by mail.equinux.net (equinux Secure mail Relay) with ESMTP; Tue, 31 May 2011 12:10:45 +0200
Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id 1554121C9B19; Tue, 31 May 2011 13:43:20 +0200 (CEST)
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Markus Hanauska 
In-Reply-To: 
Date: Tue, 31 May 2011 13:43:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <36DA3A09-4581-43F3-B86E-CD9D63FE6012@equinux.de>
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>  <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de>  <805C1C3B-616E-4B2C-8774-5890E79BA13B@equinux.de> 
To: Mohacsi Janos 
X-Mailer: Apple Mail (2.1084)
X-Mlf-Version: 7.2.1.2841
X-Mlf-UniqueId: o201105311010450081675
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: Tue, 31 May 2011 11:43:21 -0000

On 2011-05-31, at 13:09 , Mohacsi Janos wrote:

>>> What collision? You should use 'u' bit accrdingly:
>>> 1 - if automaticaly assigned
>>> 0 - if manually assigned.
>>=20
>> But it is also 0 for SLAAC addresses w/ privacy extension and those =
are automatically assigned, in example.
>=20
> You can argument for change in the RFC 4941 revision.

When I first mentioned this topic here on the list, I got the impression =
that there will never be a consent for such a change.

Regards,
Markus=

From swmike@swm.pp.se  Tue May 31 04:45: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 E0A3FE080B for ; Tue, 31 May 2011 04:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 Xhf5k2Np7dib for ; Tue, 31 May 2011 04:45:45 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id C8CF8E07C6 for ; Tue, 31 May 2011 04:45:44 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 49C529C; Tue, 31 May 2011 13:45:43 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 489EA9A; Tue, 31 May 2011 13:45:43 +0200 (CEST)
Date: Tue, 31 May 2011 13:45:43 +0200 (CEST)
From: Mikael Abrahamsson 
To: Philip Homburg 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
In-Reply-To: 
Message-ID: 
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>     
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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: Tue, 31 May 2011 11:45:47 -0000

On Tue, 31 May 2011, Philip Homburg wrote:

> I have no idea why you want hosts on the same vlan and then use L2 
> filtering to prevent them from communicating directly. But yes, if the 
> router would then start sending redirects, it would create a mess.

This has been a common deployment scenario for ETTH for the past 10 years.

On IPv4, this was done by means of local-proxy-arp by the gateway, which 
is suboptimal for other reasons.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

From mohacsi@niif.hu  Tue May 31 04:52:53 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 726ABE0704 for ; Tue, 31 May 2011 04:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level: 
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245]
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 X44DzY5rpXvr for ; Tue, 31 May 2011 04:52:52 -0700 (PDT)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 39B9DE068E for ; Tue, 31 May 2011 04:52:52 -0700 (PDT)
Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 8FD15874CD; Tue, 31 May 2011 13:52:50 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu
Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id G-waF6PmTEoe; Tue, 31 May 2011 13:52:45 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 082FE87500; Tue, 31 May 2011 13:52:45 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id F2328874F8; Tue, 31 May 2011 13:52:44 +0200 (CEST)
Date: Tue, 31 May 2011 13:52:44 +0200 (CEST)
From: Mohacsi Janos 
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Markus Hanauska 
Subject: Re: [ipv6] Node Requirements: Elevating DHCPv6 from MAY to SHOULD
In-Reply-To: <98089550-58BD-48C2-84BD-7A0A9223F1B3@equinux.de>
Message-ID: 
References: <4DE3F87A.5060502@globis.net>   <98089550-58BD-48C2-84BD-7A0A9223F1B3@equinux.de>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Thomas Narten , Ray Hunter , ipv6@ietf.org, Ralph Droms 
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, 31 May 2011 11:52:53 -0000

Hi,

You quoting is misleading - you getting out of context my answers.


On Tue, 31 May 2011, Markus Hanauska wrote:

>
> On 2011-05-31, at 11:57 , Mohacsi Janos wrote:
>
>> What about the ordering, if you get more than one DHCP addresses?
>
> How would this be any different to the situation as we have it today? 
> It's rather strange arguing to say something introduces a problem, if 
> this is not a new problem, but one that is in existence already by the 
> current standards. In whatever way this situation is handled today, it 
> would be handled the same way, I'd say.

Yes. Your address list has 4 element, mine list can have 5 or even more. 
You ordering is incomplete. I agree, It has to be handled in the same way:
bind() to proper address.

>
>> From operating system point of view all the addresses are the same.
>
> This is not quite true. If I have a SLAAC address with interface ID and 
> one with Priv Ext, all systems I know prefer the one with Priv Ext for 
> outgoing traffic, unless a client/server software explicitly picks 
> another one. The same thing could be the case for DHCP addresses.

This is not quite true either. You can select in some OS, to prefer 
privacy address or not. For DHCP, I don't see difference between static 
and DHCP assigned.

>
>>  The RFC 4941 states, that usage of Privacy enhanced addresses can be 
>> selected based on the destination addresses.
>
> Yes, but there is nothing special about this. Every address can be 
> picked according to the destination address simply by adding a routing 
> table entry for a certain destination or destination range; this also 
> works with IPv4.

Will it work this way on all the operating systems?

>
>> Not with SLAAC, but static addresses.
>
> My impression was the consent on this list is that static addresses are 
> evil(TM), since it is the most error prone way of assigning addresses on 
> a network. And I cannot really disagree, there is some truth in that 
> statement. Also it is more painful to remotely log into hosts and 
> manually assign them IPs, instead of managing all this in a central 
> place: The DHCP server config.

I am referring here the assigning static addresses to stable servers (to 
avoid problems of MAC address changes). For address assignment 
point of view static and DHCP is the almost the same. DHCP slightly worse, 
since you are relying operation of your DHCP server. Or slightly better, 
you have the assigned addresses in one database.

Regards,
 	Janos Mohacsi

From pch-b2B3A6689@u-1.phicoh.com  Tue May 31 05:01: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 456ABE0830 for ; Tue, 31 May 2011 05:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.484
X-Spam-Level: 
X-Spam-Status: No, score=-8.484 tagged_above=-999 required=5 tests=[AWL=0.115,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
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 p79506OfsX12 for ; Tue, 31 May 2011 05:01:31 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id AE253E083B for ; Tue, 31 May 2011 05:01:30 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QRNdZ-0001gtC; Tue, 31 May 2011 14:01:29 +0200
Message-Id: 
To: Markus Hanauska 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>  <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de>  <568E4F89-520A-4362-B0FA-7B64A5B82139@equinux.de> 
In-reply-to: Your message of "Tue, 31 May 2011 13:19:39 +0200 ." <568E4F89-520A-4362-B0FA-7B64A5B82139@equinux.de> 
Date: Tue, 31 May 2011 14:01:28 +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: Tue, 31 May 2011 12:01:32 -0000

In your letter dated Tue, 31 May 2011 13:19:39 +0200 you wrote:
>On 2011-05-31, at 12:35 , Philip Homburg wrote:
>> The difference is that IPv4 has a model of one subnet per link.
>
>Why do you think so? The computer I'm using right now has two IP =
>addresses of different IP subnets on the same network interface (and I =
>really mean the same layer 2 network, there are no VLANs in use). I =
>think pretty much any operating system as of today allows for such a =
>configuration.

I would say that having an interface with two IPv4 addresses is not really in
the model.

But specifically, you may find that for each of those two addresses the host
will treat only the subnet associated with the address as on-link. 

>> That's always that case if you want a configuration that is not =
>mainstream:
>> you either have to buy a more expensive product that has more =
>configuration
>> options or, in many cases, you can also use open source.
>
>But don't you think it helps a lot to push a new technology to =
>mainstream if it is possible to also use this technology without any =
>expensive hardware or complicated configurations? 

There will always be people/organisation who are different from mainstream.

For example, for the IPv6 setup I'm running at home there are no specs at all.

>1) A need for DHCPv6 right from the start and taking it into =
>consideration everywhere SLAAC was taken into consideration. E.g. is =
>this thread; DHCPv6 should have been "SHOULD" right from day one.

I have no idea where that went wrong. 

But SHOULD is a bit tricky in that context. If you assume that statefull
DHCPv6 is expensive (compare to SLAAC) and you want to support extremely
minimal devices, then SHOULD may just be a bit too strong.

>2) A better way to run SLAAC, SLAAC + Privacy Ext, DHCP and manual =
>addressing all on the same link *AND* same prefix in such a way, that it =
>is almost address conflict free without having to rely on ND to discover =
>conflicts (since ND will fail for hosts currently offline, but with =
>reserved addresses): Defining all addressing schemes in such a way, that =
>they don't interfere with each other under "normal" operation conditions =
>- of course MAC address conflicts are still possible, two nodes with =
>SLAAC + Priv Ext may also collide (only ND can avoid that) and =
>misconfiguration will always be possible; but I consider none of these =
>as normal operation conditions). Only two flags in 64 bit node addresses =
>would have been necessary for that.

I'm not sure that a bit that distinguishes manual configuration from DHCP is
a good thing. SLAAC with EUID already has its bit.

So the only thing that remains is how much faith you have in a random number
generator. I think it is no problem, but we have to wait for large scale
deployment to see if that is justified.

>3) No M/O bits in router advertise messages. Every interface can have a =
>manually configured address, a DHCPv6 address, a SLAAC address, a SLAAC =
>w/ Priv Ext and that for every prefix it is aware of. The order of =
>preference for outgoing traffic is configurable, the default order is =
>defined in any RFC (e.g. I would suggest manual, DHCP, SLAAC w/ Priv =
>Ext, SLAAC).

Some people were worried about useless DHCP traffic. I'm not sure if that
is justified. But just setting those bits in the router config should be no
problem. That only leaves the case where there is no router. If everybody 
always sets those bits, then maybe routers will have them as standard.

>4) Considering DNS right from the start, since DNS is almost critical =
>for many networks as of today. If one of the IPv6 main design goal was =
>to allow the majority of networks to operate without a DHCP server (and =
>it looks as if it was, otherwise DHCPv6 would have been taken much more =
>into account), something like RFC 6106 (former 5006) was missing way too =
>long IMHO. Though I still fail to see the need for this RFC at all; I =
>had rather said that for simple setups that don't provide DNS servers =
>via DHCP, it would have been enough to have a well defined anycast or =
>even multicast address for DNS servers (I don't know any real life =
>network where DNS server addresses changes so frequently, that this =
>wouldn't work well in practice).

There is a difference between statefull and stateless DHCPv6. I think NTP
is also pretty important.

This is just one of those things that have to be corrected based on real 
world experience. Unfortunately, the real world ignored IPv6 for 15 years.
So only now do those things get fixed.



From hanauska@equinux.de  Tue May 31 05:07:38 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 726E3E0826 for ; Tue, 31 May 2011 05:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 LPSdxXsaOOqe for ; Tue, 31 May 2011 05:07:37 -0700 (PDT)
Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6C501E07A7 for ; Tue, 31 May 2011 05:07:37 -0700 (PDT)
Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hsj25c0171se for ; Tue, 31 May 2011 12:35:01 +0200 (envelope-from )
Received: from mail.muc.equinux.net ([192.168.40.207]) by mail.equinux.net (equinux Secure mail Relay) with ESMTP; Tue, 31 May 2011 12:35:01 +0200
Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id 8A28C21C9BE0; Tue, 31 May 2011 14:07:36 +0200 (CEST)
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Markus Hanauska 
In-Reply-To: 
Date: Tue, 31 May 2011 14:07:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <64155E17-D08D-4B98-AD1A-A21CE6462147@equinux.de>
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>  <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de>  <568E4F89-520A-4362-B0FA-7B64A5B82139@equinux.de> 
To: Mohacsi Janos 
X-Mailer: Apple Mail (2.1084)
X-Mlf-Version: 7.2.1.2841
X-Mlf-UniqueId: o201105311035010081940
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: Tue, 31 May 2011 12:07:38 -0000

On 2011-05-31, at 13:38 , Mohacsi Janos wrote:

> I disagree with introduction of another flags. This requires =
substantial changes in the codes.... Which will take ages....

I took a look at the IPv6 implementations of Mac OS X (which comes from =
the BSD world) and Linux a couple of weeks ago. Introducing such a =
second flag can be done with only a hand full of code lines and those =
can be written in about 30 minutes. Basically this flag only needs to be =
set for all SLAAC addresses, that's all there is to be done. We call =
this flag A, for automatically assigned, and keep the existing U flag, =
for globally unique. Then we have the following cases:

Manual (Static) Address: U =3D 0, A =3D 0
DHCP Address: U =3D 0, A =3D 0
SLAAC: U =3D 1, A =3D 1
SLAAC + Priv Ext: U =3D 0, A =3D 1

Now only DHCP and Static Addresses can collide and this would happen in =
case of a misconfiguration; it is impossible to prevent =
misconfigurations, so you shouldn't even try.

Right now SLAAC + Priv Ext can collide with Static/DHCP addresses (e.g. =
while the host is offline, ND will not detect such a collision and when =
the host goes online, it cannot get its address any longer, since it is =
taken by a SLAAC host). If we would define SLAAC + Priv Ext to set the U =
bit (which would be wrong, since these addresses are not globally =
unique), then it could collide with SLAAC addresses of hosts currently =
offline (again, ND will not work here and those host cannot go online =
later because their interface ID collides with an address already in =
use).

> We need M/O bits to give some sort of consistency.

May I ask what kind of consistency are you referring to?

> Nothing prevent you the suggest an draft document for multicast or =
anycast resolving DNS.

I consider it way too late to start such a project as of today. This =
should have been standardized already when the other well known =
multicast/anycast addresses were standardized.

> There is environment where SLAAC more acceptable - e.g. less =
adminisration

My home DSL router supports IPv6 and the difference between SLAAC and =
DHCPv6 is one checkbox; check it, and it runs a DHCPv6 server. There is =
nothing else you have to configure - you can configure address pools, =
static assignments, which DNS servers to hand out and other options, but =
you don't have to, if you don't feel like it. So I cannot really =
comprehend what is so hard about DHCP administration. Most =
routers/firewalls as of today have a build in DHCPv4 server and in the =
worst case, you'll have to enter a DNS server, create an address pool =
and enable it - not really a lot of administration work - in the best =
case, it will configure all of that automatically for you and you only =
have to customize settings if you feel like doing so (most home routers =
have DHCPv4 enabled and pre-configured, so for most users it means, plug =
your computer into the router or connect to the WLAN and it works out of =
the box, nothing to configure at all, except for internet access).


Regards,
Markus=

From tjc@ecs.soton.ac.uk  Tue May 31 05:44:14 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 B6BEDE078D for ; Tue, 31 May 2011 05:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 OJGDOYbBzaks for ; Tue, 31 May 2011 05:44:10 -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 F05ACE076F for ; Tue, 31 May 2011 05:44:07 -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 p4VCi4mV006247 for ; Tue, 31 May 2011 13:44:04 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p4VCi4mV006247
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1306845844; bh=G8hypoRkHP4DHqAIMjDwjUwjOno=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=ffDGIKL0P/Z7uNFQZXibtnJNFKeQh2egyDJzfoulF3Hz71pUYNOVQLZ+WWnEuaAQ7 S+K2llOT5VAfXxMNaWW4ZJAGjdjGA+TW2doaQLTjqIWQBNdckmsfrqbshGMG1hOOBb +5vbTvEudJG6c7mtmjlWBms7qWg6aGpyLNmwI1Wk=
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 n4UDi40035602278iZ ret-id none; Tue, 31 May 2011 13:44:04 +0100
Received: from dhcp-152-78-94-254.ecs.soton.ac.uk (dhcp-152-78-94-254.ecs.soton.ac.uk [152.78.94.254]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p4VChwsH025209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 31 May 2011 13:43:58 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]
From: Tim Chown 
In-Reply-To: <4BC7CABA-D871-4B27-96BA-10A2F9D6D2B1@cisco.com>
Date: Tue, 31 May 2011 13:43:58 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <4DE3F87A.5060502@globis.net> <4DE40821.9030205@gmail.com> <4DE420E2.6010207@globis.net> <4BC7CABA-D871-4B27-96BA-10A2F9D6D2B1@cisco.com> <3C7CD9FA-6220-4CE6-921B-ABF2719E4189@ecs.soton.ac.uk>
To: ipv6@ietf.org
X-Mailer: Apple Mail (2.1084)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n4UDi4003560227800; tid=n4UDi40035602278iZ; 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: p4VCi4mV006247
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, 31 May 2011 12:44:14 -0000

On 31 May 2011, at 03:38, Fred Baker wrote:
>=20
> I would expect, however, that the use of DHCP is something configured =
on the system in question, just like it is in IPv4. Not that there is an =
auto-configure option in IPv4 - the other alternative is manual =
configuration, and most systems come with DHCP configured as the =
default. IPv6 systems come, at least today, with SLAAC as the default. =
So there is a requirement to configure DHCPv6, at least from that =
perspective. That said, SLAAC ain't gonna happen in the absence of RAs, =
and you can disable RAs on the router. So if an interface comes up and =
no RA is forthcoming, I could imagine the thing probing with a DHCPv6 =
request.

But then it can't get a default router configuration by DHCPv6?

It's interesting that my 18(?) month old HP Laserjet n model has IPv6 =
support, and even being that old can be configured to=20

a) just autoconfigure
b) use DHCPv6 when the M bit is set in the RA
c) use DHCPv6 when stateless autoconfig fails
d) always use DHCPv6
or
e) use a manually-configured IPv6 address.=20

If you're interested in how that appears via the HP web config screen, =
see a screenshot at =
http://users.ecs.soton.ac.uk/tjc/ietf/hplaserjet-example.png

I think, but am not sure, that the screenshot shows the default =
configuration.  While there is no privacy addressing in this example, =
that could be an additional option, though it makes little sense for =
such a device.

To me, if you want to run DHCPv6, you set the RA M bit, and it's then =
down to hosts to choose to honour that.  But if you don't have =
management control of any device, unless you put additional measures in =
place, the host can always be configured with a different/additional =
address to that offered by DHCPv6.=20

Tim


From hanauska@equinux.de  Tue May 31 05:45: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 D145CE07A7 for ; Tue, 31 May 2011 05:45:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 lkrtJlGcMgfS for ; Tue, 31 May 2011 05:45:25 -0700 (PDT)
Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4B254E07A3 for ; Tue, 31 May 2011 05:45:25 -0700 (PDT)
Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hsj6j20171si for ; Tue, 31 May 2011 13:12:48 +0200 (envelope-from )
Received: from mail.muc.equinux.net ([192.168.40.207]) by mail.equinux.net (equinux Secure mail Relay) with ESMTP; Tue, 31 May 2011 13:12:48 +0200
Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id 3CA8E21C9D0B; Tue, 31 May 2011 14:45:24 +0200 (CEST)
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Markus Hanauska 
In-Reply-To: 
Date: Tue, 31 May 2011 14:45:24 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>  <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de>  <568E4F89-520A-4362-B0FA-7B64A5B82139@equinux.de> 
To: Philip Homburg 
X-Mailer: Apple Mail (2.1084)
X-Mlf-Version: 7.2.1.2841
X-Mlf-UniqueId: o201105311112480082263
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: Tue, 31 May 2011 12:45:26 -0000

On 2011-05-31, at 14:01 , Philip Homburg wrote:

> I would say that having an interface with two IPv4 addresses is not =
really in
> the model.

Maybe it is rather uncommon, but it is allowed and also supported by all =
major operating systems; just wanted to point that out.

> But SHOULD is a bit tricky in that context. If you assume that =
statefull
> DHCPv6 is expensive (compare to SLAAC) and you want to support =
extremely
> minimal devices, then SHOULD may just be a bit too strong.

Is DHCPv6 more expensive than DHCPv4? Since even the most minimalistic =
device with IPv4 support I know of has DHCPv4 support; however, you  =
might be referring to devices even more minimalistic than what I have in =
mind. I just would like to point out, that I already wrote a DHCPv4 =
client myself (for a software project) - not fully featured, it only =
cares for an IP address, a subnet mask, DNS servers, DNS domain and the =
lease time, all other options are pretty much ignored - and I was =
surprised how little code I needed for that. It is pretty robust and so =
far worked well with every DHCP server we ever found. It even supports =
renewing the lease, though it does not fully implement the state-flow of =
the RFC (which seems over complicated IMHO). So a device that is not =
able to run such a simple client must be really, very, very minimalistic =
and my impression is that DHCPv6 is much simpler than DHCPv4, since it =
is not an extension to BOOTP (which makes DHCPv4 harder to implement =
than would otherwise be necessary).

> I'm not sure that a bit that distinguishes manual configuration from =
DHCP is
> a good thing. SLAAC with EUID already has its bit.

I'm not advocating to make DHCP and manual configuration =
distinguishable, but to make SLAAC with Priv Ext distinguishable of DHCP =
and manual addresses:

Manual (Static) Address: U =3D 0, A =3D 0
DHCP Address: U =3D 0, A =3D 0
SLAAC: U =3D 1, A =3D 1
SLAAC + Priv Ext: U =3D 0, A =3D 1

> So the only thing that remains is how much faith you have in a random =
number
> generator. I think it is no problem, but we have to wait for large =
scale
> deployment to see if that is justified.

As a programmer, I don't believe in randomness but in predictability. =
You don't write code that  will only crash in one out of hundred billion =
cases if you can write code that will never crash for sure - even if the =
first case is so unlikely, that you may never see the code crash in your =
whole life.

However, we are losing the point here: With IPv6 I just fail to see the =
argument SLAAC vs DHCPv6, since there is no real reason IMHO for =
either/or and I fail to see how this is helpful if there are networks =
based on SLAAC and networks based on DHCPv6, this only adds unnecessary =
inconsistency. And people make it even worse by requesting a flag to =
control whether nodes may use privacy extension or not. Why not make it =
consistent: Every network is always SLAAC, even if there is a DHCP =
server, it is SLAAC. Privacy Extension is always possible to protect =
people's privacy if they feel like it. And only DHCP is optional, but =
when it is available, it does not replace SLAAC, it "completes" it and =
either hands out an IP address or not, but even when it hands out an IP =
address, it does not replace SLAAC. And thus I don't really see any need =
for an M or O flag in a RA message. Clients supporting DHCP will always =
try DHCP when a link comes up. Really, this traffic is so little =
compared to current network speeds, it's absolutely insignificant.

Regards,
Markus=

From mohacsi@niif.hu  Tue May 31 06:12:54 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 BE3CCE06A6 for ; Tue, 31 May 2011 06:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.004
X-Spam-Level: 
X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245]
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 APkKIJirds8r for ; Tue, 31 May 2011 06:12:50 -0700 (PDT)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB35E0708 for ; Tue, 31 May 2011 06:12:49 -0700 (PDT)
Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id 9ADF38750E; Tue, 31 May 2011 15:12:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu
Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id Fp4fcwQfioKp; Tue, 31 May 2011 15:12:41 +0200 (CEST)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 9D60887508; Tue, 31 May 2011 15:12:41 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 9AB8E87505; Tue, 31 May 2011 15:12:41 +0200 (CEST)
Date: Tue, 31 May 2011 15:12:41 +0200 (CEST)
From: Mohacsi Janos 
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Markus Hanauska 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
In-Reply-To: <64155E17-D08D-4B98-AD1A-A21CE6462147@equinux.de>
Message-ID: 
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>  <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de>  <568E4F89-520A-4362-B0FA-7B64A5B82139@equinux.de>  <64155E17-D08D-4B98-AD1A-A21CE6462147@equinux.de>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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: Tue, 31 May 2011 13:12:54 -0000

On Tue, 31 May 2011, Markus Hanauska wrote:

>
> On 2011-05-31, at 13:38 , Mohacsi Janos wrote:
>
>> I disagree with introduction of another flags. This requires 
>> substantial changes in the codes.... Which will take ages....
>
> I took a look at the IPv6 implementations of Mac OS X (which comes from 
> the BSD world) and Linux a couple of weeks ago. Introducing such a 
> second flag can be done with only a hand full of code lines and those 
> can be written in about 30 minutes. Basically this flag only needs to be 
> set for all SLAAC addresses, that's all there is to be done. We call 
> this flag A, for automatically assigned, and keep the existing U flag, 
> for globally unique. Then we have the following cases:
>
> Manual (Static) Address: U = 0, A = 0
> DHCP Address: U = 0, A = 0
> SLAAC: U = 1, A = 1
> SLAAC + Priv Ext: U = 0, A = 1


I agree it can be written. Deployment of the code is another story. E.g. 
your cited Mac OS X example: RFC 3484 is written for BSD around 2003. The 
current Mac OS X still does not have it properly implemented.

>
>
> May I ask what kind of consistency are you referring to?


Consistency from administrator point of: Administrator have hint what is 
supplied with M/O bits: managed addresses via DHCP, other configuration 
information via DHCP.

>
>> Nothing prevent you the suggest an draft document for multicast or anycast resolving DNS.
>
> I consider it way too late to start such a project as of today. This 
> should have been standardized already when the other well known 
> multicast/anycast addresses were standardized.


Please write a draft.


>
>> There is environment where SLAAC more acceptable - e.g. less adminisration
>
> My home DSL router supports IPv6 and the difference between SLAAC and 
> DHCPv6 is one checkbox; check it, and it runs a DHCPv6 server. There is 
> nothing else you have to configure - you can configure address pools, 
> static assignments, which DNS servers to hand out and other options, but 
> you don't have to, if you don't feel like it. So I cannot really 
> comprehend what is so hard about DHCP administration. Most 
> routers/firewalls as of today have a build in DHCPv4 server and in the 
> worst case, you'll have to enter a DNS server, create an address pool 
> and enable it - not really a lot of administration work - in the best 
> case, it will configure all of that automatically for you and you only 
> have to customize settings if you feel like doing so (most home routers 
> have DHCPv4 enabled and pre-configured, so for most users it means, plug 
> your computer into the router or connect to the WLAN and it works out of 
> the box, nothing to configure at all, except for internet access).

Have a look at RFC 6204
http://tools.ietf.org/html/rfc6204
and join to the discussion of

http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-bis-00

>
>
> Regards,
> Markus

From pch-b2B3A6689@u-1.phicoh.com  Tue May 31 06:26: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 397B3E06A6 for ; Tue, 31 May 2011 06:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.494
X-Spam-Level: 
X-Spam-Status: No, score=-8.494 tagged_above=-999 required=5 tests=[AWL=0.105,  BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4]
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 01eYLZxPPKWO for ; Tue, 31 May 2011 06:26:16 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 99A8CE07B2 for ; Tue, 31 May 2011 06:26:14 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #55) id m1QROxZ-0001imC; Tue, 31 May 2011 15:26:13 +0200
Message-Id: 
To: Markus Hanauska 
Subject: Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD 
From: Philip Homburg 
Sender: pch-b2B3A6689@u-1.phicoh.com
References:  <201105232010.p4NKAV9X012654@cichlid.raleigh.ibm.com> <53E999C4-E50D-49C9-9B02-8AD7B5641905@gmail.com>  <201105232111.p4NLBScJ013180@cichlid.raleigh.ibm.com> <20110524072631.737ee12c@opy.nosense.org> <3044C560-F46C-477A-BD87-DF252F689FAB@equinux.de>  <62797F6E-20DF-4038-A29A-1FDB0A94C678@equinux.de>  <075E5D04-AF53-4DE9-9F45-432D96EBB03F@equinux.de>  <568E4F89-520A-4362-B0FA-7B64A5B82139@equinux.de>   
In-reply-to: Your message of "Tue, 31 May 2011 14:45:24 +0200 ."  
Date: Tue, 31 May 2011 15:26:12 +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: Tue, 31 May 2011 13:26:17 -0000

In your letter dated Tue, 31 May 2011 14:45:24 +0200 you wrote:
>Is DHCPv6 more expensive than DHCPv4? Since even the most minimalistic =
>device with IPv4 support I know of has DHCPv4 support; however, you  =
>might be referring to devices even more minimalistic than what I have in =
>mind. 

I wasn't there. 

Similar arguments were repeated for the DNS option in the RA: a stateless
DHCPv6 query was too much hassle.


>As a programmer, I don't believe in randomness but in predictability. =
>You don't write code that  will only crash in one out of hundred billion =
>cases if you can write code that will never crash for sure - even if the =
>first case is so unlikely, that you may never see the code crash in your =
>whole life.

The question is, what do you gain? Do you expect an actual increase in
reliability? If there are many thing that can go wrong and are likely to
go wrong, then changing one possible fault from very unlikely to designed to
be impossible doesn't really contribute to the overall reliability of the
system.

>However, we are losing the point here: With IPv6 I just fail to see the =
>argument SLAAC vs DHCPv6, since there is no real reason IMHO for =
>either/or and I fail to see how this is helpful if there are networks =
>based on SLAAC and networks based on DHCPv6, this only adds unnecessary =
>inconsistency. And people make it even worse by requesting a flag to =
>control whether nodes may use privacy extension or not. Why not make it =
>consistent: Every network is always SLAAC, even if there is a DHCP =
>server, it is SLAAC. Privacy Extension is always possible to protect =
>people's privacy if they feel like it. And only DHCP is optional, but =
>when it is available, it does not replace SLAAC, it "completes" it and =
>either hands out an IP address or not, but even when it hands out an IP =
>address, it does not replace SLAAC. And thus I don't really see any need =
>for an M or O flag in a RA message. Clients supporting DHCP will always =
>try DHCP when a link comes up. Really, this traffic is so little =
>compared to current network speeds, it's absolutely insignificant.

You get turning SLAAC on and off for free (you need that flag to be able to 
mark a prefix as on-link without allowing hosts to use that prefix as source
address).

As far as I know, the ability to turn DHCPv6 on or off was based on the
amount of network traffic it would generate, so you also get that more of
less for free.

Privacy extension are tricky. The owner of the host and the owner of the
network may have conflicting interests. I'm sure that all network operators
would agree with hosts generally preferring addresses with privacy extensions.



From ipng@69706e6720323030352d30312d31340a.nosense.org  Tue May 31 06:28: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 B8A6BE079A for ; Tue, 31 May 2011 06:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.951
X-Spam-Level: 
X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
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 7+7uunZbhsNh for ; Tue, 31 May 2011 06:28:42 -0700 (PDT)
Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2ADE0708 for ; Tue, 31 May 2011 06:28:39 -0700 (PDT)
Received: from 219-90-148-106.ip.adam.com.au ([219.90.148.106] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QROzh-00036b-Ec; Tue, 31 May 2011 22:58:25 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id EE80A3B33D; Tue, 31 May 2011 22:58:24 +0930 (CST)
Date: Tue, 31 May 2011 22:58:24 +0930
From: Mark Smith 
To: Markus Hanauska 
Subject: Re: [ipv6] Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Message-ID: <20110531225824.11c3251d@opy.nosense.org>
In-Reply-To: 
References: <4DE3F87A.5060502@globis.net> 
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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: Thomas Narten , Ray Hunter , ipv6@ietf.org, Ralph Droms 
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, 31 May 2011 13:28:46 -0000

On Tue, 31 May 2011 11:29:49 +0200
Markus Hanauska  wrote:

> 
> On 2011-05-30, at 22:05 , Ray Hunter wrote:
> 
> > Which source address (SLAAC/DHCPv6) would be used by the client for an outbound session if a SLAAC address and a DHCPv6 were both configured on the same link and with the same prefix, in the absence of a flag?
> 
> As I already said in my previous mail: The DHCP address should win by default; that is, of course, unless the admin/user of the node has configured anything else. If a network runs a DHCP server that hands out addresses, network admins probably do so for a reason. The SLAAC one is valid and inbound traffic might arrive for it, but for outgoing traffic, some RFC should simply have given an order of preference:
> 
> 1. Manual configured IP
> 2. DHCP
> 3. SLAAC with Privacy Extension
> 4. SLAAC with Interface ID
> 

Some people might prefer SLAAC over DHCP. For example, if I were
attached to a public hot spot with my laptop, then I'd want to use 
SLAAC with Privacy Extensions in preference to DHCP, even if there is a
DHCP server available.


> >  Think dynamic DNS too: which (destination) address(es) would be auto registered at the server end?
> 
> All of them, since a single DNS entry can resolve to plenty of different IP addresses (DNS has always been designed to allow this scenario). The order should be the same as the order of preference above, though you can argue if it is meaningful to register Privacy Extension addresses at all, since they will dynamically change pretty often.
> 
> > There are a lot of operational people who currently rely on having predictable IP addresses for accounting, audit, scripting, firewall rules, neighbor filtering, fault tracing, reverse DNS, policy based routing, setting DSCP in QoS, any other number of ACL's  ....
> 
> I can also totally agree with your statement above - but there is one thing you are missing: It is not only important, to have predictable IP addresses in some scenarios, it is also important to have "constant" IP addresses, since even if the address is predictable, it will be a problem if it is going to change every couple of months. SLAAC addresses based on interface IP are in fact predictable; but they not constant! On the other hand, when using DHCP, it takes me 2 minutes to change the stored interface ID of a DHCP client in the server config to assure, that even after an interface ID change, the client still gets the same IP address as before. How will you do this with SLAAC? Manually configuring the same MAC address as the old interface? You shouldn't manually assign MAC addresses, if not really necessary, especially not those which claim to be globally unique, even though they are in fact not. MAC address collisions are worst case scenarios for most networks. Further
  c
>  ertain clients, e.g. take an iPhone or iPad, don't allow you to change interface IDs at all AFAIK.
> 
> Regards,
> Markus
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

From hanauska@equinux.de  Tue May 31 06:50: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 B1209E07EB for ; Tue, 31 May 2011 06:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
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 44cNeuqs8sPr for ; Tue, 31 May 2011 06:50:18 -0700 (PDT)
Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by ietfa.amsl.com (Postfix) with ESMTP id DACD6E071F for ; Tue, 31 May 2011 06:50:17 -0700 (PDT)
Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hsje6a0171s7 for ; Tue, 31 May 2011 14:17:40 +0200 (envelope-from )
Received: from mail.muc.equinux.net ([192.168.40.207]) by mail.equinux.net (equinux Secure mail Relay) with ESMTP; Tue, 31 May 2011 14:17:40 +0200
Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id 04D4A21C9F90; Tue, 31 May 2011 15:50:17 +0200 (CEST)
Subject: Re: [ipv6] Node Requirements: Elevating DHCPv6 from MAY to SHOULD
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Markus Hanauska 
In-Reply-To: <20110531225824.11c3251d@opy.nosense.org>
Date: Tue, 31 May 2011 15:50:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7272D712-99C5-45C7-956E-B24ACE885A2D@equinux.de>
References: <4DE3F87A.5060502@globis.net>  <20110531225824.11c3251d@opy.nosense.org>
To: Mark Smith 
X-Mailer: Apple Mail (2.1084)
X-Mlf-Version: 7.2.1.2841
X-Mlf-UniqueId: o201105311217400082633
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: Tue, 31 May 2011 13:50:19 -0000

On 2011-05-31, at 15:28 , Mark Smith wrote:

>> 1. Manual configured IP
>> 2. DHCP
>> 3. SLAAC with Privacy Extension
>> 4. SLAAC with Interface ID
>>=20
>=20
> Some people might prefer SLAAC over DHCP.

That's why things like these are usually configurable. Just because =
there exists a well defined default order doesn't mean you are not =
allowed to manually override it, does it?

> For example, if I were
> attached to a public hot spot with my laptop, then I'd want to use=20
> SLAAC with Privacy Extensions in preference to DHCP, even if there is =
a
> DHCP server available.

I doubt this would buy you anything. See, if the network admin was okay =
with people using SLAAC, he wouldn't hand out IP addresses through =
DHCPv6. Either he would not operate a DHCPv6 server at all or he would =
only operate a stateless DHCPv6 server to hand out DNS, NTP and other =
useful server addresses. Do you know of any device that supports DHCPv6 =
but not SLAAC? I don't. Would such a device be even standard conform? So =
if the admin operates a DHCPv6 server at that hotspot handing out IP =
address, he probably wants you to use those addresses and all other =
addresses may, for example, not be routable, that means if you override =
the order above, your outgoing traffic works within the hotspot only, =
but you cannot reach the rest of the Internet any longer and since =
hotspots usually put the user into virtual LANs and don't allow direct =
traffic between two hotspot users, there is nothing you could do while =
being connected to the hotspot.

Regards,
Markus=

From jhw@apple.com  Tue May 31 09:24: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 1B3E2E07EC for ; Tue, 31 May 2011 09:24:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv3dDqBUlzT6 for ; Tue, 31 May 2011 09:24:33 -0700 (PDT)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id C2116E07F9 for ; Tue, 31 May 2011 09:24:27 -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 <0LM200IKYILW2RD1@mail-out.apple.com> for ipv6@ietf.org; Tue, 31 May 2011 09:24:27 -0700 (PDT)
X-AuditID: 11807134-b7c00ae0000074fb-7a-4de5163b327d
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 00.16.29947.B3615ED4; Tue, 31 May 2011 09:24:27 -0700 (PDT)
Received: from [17.113.33.178] (unknown [17.113.33.178]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LM2003BZIWKK050@koseret.apple.com> for ipv6@ietf.org; Tue, 31 May 2011 09:24:26 -0700 (PDT)
Subject: Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]
From: james woodyatt 
In-reply-to: <4BC7CABA-D871-4B27-96BA-10A2F9D6D2B1@cisco.com>
Date: Tue, 31 May 2011 09:24:19 -0700
Message-id: 
References: <4DE3F87A.5060502@globis.net> <4DE40821.9030205@gmail.com> <4DE420E2.6010207@globis.net> <4BC7CABA-D871-4B27-96BA-10A2F9D6D2B1@cisco.com>
To: 6MAN 
X-Mailer: Apple Mail (2.1227)
X-Brightmail-Tracker: AAAAAA==
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, 31 May 2011 16:24:34 -0000

On May 30, 2011, at 7:38 PM, Fred Baker wrote:
> 
> [...] IPv6 systems come, at least today, with SLAAC as the default. So there is a requirement to configure DHCPv6, at least from that perspective. That said, SLAAC ain't gonna happen in the absence of RAs, and you can disable RAs on the router. So if an interface comes up and no RA is forthcoming, I could imagine the thing probing with a DHCPv6 request. [...]

For what it's worth, the behavior of Apple's iOS 4.3 and later is straightforward.  If there is no RA, then there is no IPv6.  iOS 4.3 doesn't support manual IPv6 configuration, so automatic configuration is the only way to plumb it.  The DHCPv6 client only starts if the router indicates availability with O=1.  Remember when I was complaining that we needed RFC 6106 for the O=0 case?  Given that we have that, I don't see any benefit to starting the DHCPv6 client unless a router explicitly tells us to expect service.  No router?  No need for dynamic host configuration.


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




From alan.kavanagh@ericsson.com  Tue May 31 10:22:11 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 42322E088E for ; Tue, 31 May 2011 10:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 XQwsCoOcmhwb for ; Tue, 31 May 2011 10:22:10 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4E93FE088C for ; Tue, 31 May 2011 10:22:10 -0700 (PDT)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p4VHM1cg024773; Tue, 31 May 2011 12:22:07 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 31 May 2011 13:22:03 -0400
From: Alan Kavanagh 
To: Mark Townsley , Erik Nordmark 
Date: Tue, 31 May 2011 13:22:02 -0400
Subject: RE: Neighbor Unreachability Detection is too impatient
Thread-Topic: Neighbor Unreachability Detection is too impatient
Thread-Index: AcwZgmYA/X0tP2XEQ+qX0cChAxVT+AGM6+Zw
Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D50B3123439F@EUSAACMS0701.eamcs.ericsson.se>
References: <4DDAAB85.8000103@acm.org> 
In-Reply-To: 
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_1B6D0317D3AD964FBF3956DEFA3524D50B3123439FEUSAACMS0701e_"
MIME-Version: 1.0
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: Tue, 31 May 2011 17:22:11 -0000

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

Hi Mark

That BBF WT-146 NUD for session monitoring was based on the idea that NUD i=
s native to IPv6 compliant devices such as host, cpe and routers and was ch=
osen as a passive way to do session monitoring.

Alan

________________________________
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Mar=
k Townsley
Sent: May-23-11 3:47 PM
To: Erik Nordmark
Cc: ipv6@ietf.org
Subject: Re: Neighbor Unreachability Detection is too impatient


Erik Kline and I wrote up an experience we had with NUD and a broken IPv6 f=
irewall on my home network.

http://sites.google.com/site/ipv6center/icmpv6-is-non-optional

In short, NUD thought that a host which was in the neighbor cache really wa=
sn't available (due to incorrect FW blocking at the host) removed it from t=
he neighbor cache and started dropping packets (and causing timeouts in gma=
il). In test, it took about 8 pings for the problem to manifest (time for N=
UD to retry enough to fail), which was followed by the classic IPv6 to IPv4=
 failover by the host (Windows Vista).

On one hand, if NUD had been more patient we may have never noticed. Howeve=
r, tracking down a bug that showed up less often would have clearly been mo=
re difficult to diagnose. Double-edged sword.

Also, the Broadband Forum's WT-146 (which isn't a public document, but if y=
ou are BBF member you can take a look at it)  specifies NUD as a monitoring=
 mechanism for "IPv6 sessions" over access links (which ultimately may be t=
ied into billing, alerts, etc.).

- Mark



On May 23, 2011, at 8:46 PM, Erik Nordmark wrote:


This draft proposes to change the requirement that NUD can not retransmit m=
ore than three times, so that NUD can be more robust against temporary netw=
ork outages.

Comments?

  Erik

-------- Original Message --------
Subject: New Version Notification for draft-nordmark-6man-impatient-nud-00.=
txt
Date: Mon, 23 May 2011 11:43:16 -0700
From: internet-drafts@ietf.org
To: nordmark@cisco.com
CC: nordmark@cisco.com

A new version of I-D, draft-nordmark-6man-impatient-nud-00.txt has been suc=
cessfully submitted by Erik Nordmark and posted to the IETF repository.

Filename: draft-nordmark-6man-impatient-nud
Revision: 00
Title: Neighbor Unreachability Detection is too impatient
Creation date: 2011-05-23
WG ID: Individual Submission
Number of pages: 5

Abstract:
  IPv6 Neighbor Discovery includes Neighbor Unreachability Detection.
  That function is very useful when a host has an alternative, for
  instance multiple default routers, since it allows the host to switch
  to the alternative in short time.  This time is 3 seconds after the
  node starts probing.  However, if there are no alternatives, this is
  far too impatient.  This document proposes an approach where an
  implementation can choose the timeout behavior to be different based
  on whether or not there are alternatives.




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


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







Hi Mark


 


That BBF WT-146 NUD for session monitoring was bas=
ed on the=20
idea that NUD is native to IPv6 compliant devices such as host, cpe an=
d=20
routers and was chosen as a passive way to do session=20
monitoring.


 


Alan


 








From:=20
ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ma=
rk=20
Townsley
Sent: May-23-11 3:47 PM
To: Erik=20
Nordmark
Cc: ipv6@ietf.org
Subject: Re: Neighbor=20
Unreachability Detection is too impatient








Erik Kline and I wrote up an experience we had with NUD and a broken I=
Pv6=20
firewall on my home network.





htt=
p://sites.google.com/site/ipv6center/icmpv6-is-non-optional





In short, NUD thought that a host which was in the neighbor cache real=
ly=20
wasn't available (due to incorrect FW blocking at the host) removed it from=
 the=20
neighbor cache and started dropping packets (and causing timeouts in gmail)=
. In=20
test, it took about 8 pings for the problem to manifest (time for NUD to re=
try=20
enough to fail), which was followed by the classic IPv6 to IPv4 failover by=
 the=20
host (Windows Vista). 





On one hand, if NUD had been more patient we may have never noticed.=20
However, tracking down a bug that showed up less often would have clearly b=
een=20
more difficult to diagnose. Double-edged sword.





Also, the Broadband Forum's WT-146 (which isn't a public document, but=
 if=20
you are BBF member you can take a look at it)  specifies NUD as a=20
monitoring mechanism for "IPv6 sessions" over access links (which ultimatel=
y may=20
be tied into billing, alerts, etc.). 





- Mark











On May 23, 2011, at 8:46 PM, Erik Nordmark wrote:



  

This draft proposes to change the requirement that NUD can not=20
  retransmit more than three times, so that NUD can be more robust against=
=20
  temporary network=20
  outages.

Comments?

  Erik

-------- Origina=
l=20
  Message --------
Subject: New Version Notification for=20
  draft-nordmark-6man-impatient-nud-00.txt
Date: Mon, 23 May 2011 11:43:=
16=20
  -0700
From: internet-drafts@ietf.org
=
To: nordmark@cisco.com
CC: nordmark@cisco.com

A new ve=
rsion=20
  of I-D, draft-nordmark-6man-impatient-nud-00.txt has been successfully=20
  submitted by Erik Nordmark and posted to the IETF=20
  repository.

Filename:=20
  draft-nordmark-6man-impatient-nud
Revision: 00
Title: Neighbor Unreach=
ability=20
  Detection is too impatient
Creation date: 2011-05-23
WG ID: Individual=20
  Submission
Number of pages: 5

Abstract:
  IPv6 Nei=
ghbor=20
  Discovery includes Neighbor Unreachability Detection.
  That=
=20
  function is very useful when a host has an alternative,=20
  for
  instance multiple default routers, since it allows the=
 host=20
  to switch
  to the alternative in short time.  This tim=
e is=20
  3 seconds after the
  node starts probing.  However, if=
=20
  there are no alternatives, this is
  far too impatient.=20
   This document proposes an approach where=20
  an
  implementation can choose the timeout behavior to be=20
  different based
  on whether or not there are=20
  alternatives.




The IETF=20
  Secretariat
----------------------------------------------------------=
----------
IETF=20
  IPv6 working group mailing list
ipv6@ietf.org
Administrative Request=
s:=20
  https://www.ietf.org/mailman/listinfo/ipv6
---------------------------=
-----------------------------------------

<=
/BODY>

--_000_1B6D0317D3AD964FBF3956DEFA3524D50B3123439FEUSAACMS0701e_--

From internet-drafts@ietf.org  Tue May 31 13:24:30 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 26708E0805; Tue, 31 May 2011 13:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.562
X-Spam-Level: 
X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Pw68eS8eur+s; Tue, 31 May 2011 13:24:29 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6EBE0675; Tue, 31 May 2011 13:24:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-ietf-6man-node-req-bis-11.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 3.55
Message-ID: <20110531202429.449.76026.idtracker@ietfa.amsl.com>
Date: Tue, 31 May 2011 13:24:29 -0700
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: Tue, 31 May 2011 20:24:30 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IPv6 Maintenance Working Group of the=
 IETF.

	Title           : IPv6 Node Requirements
	Author(s)       : Ed Jankiewicz
                          John Loughney
                          Thomas Narten
	Filename        : draft-ietf-6man-node-req-bis-11.txt
	Pages           : 31
	Date            : 2011-05-31

   This document defines requirements for IPv6 nodes.  It is expected
   that IPv6 will be deployed in a wide range of devices and situations.
   Specifying the requirements for IPv6 nodes allows IPv6 to function
   well and interoperate in a large number of situations and
   deployments.

   This document obsoletes RFC4294.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-11.txt

From v6ops@globis.net  Tue May 31 13:45: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 D6792E0871 for ; Tue, 31 May 2011 13:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.224
X-Spam-Level: 
X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6]
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 VX1ta56-yLgg for ; Tue, 31 May 2011 13:45:45 -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 A3833E07FD for ; Tue, 31 May 2011 13:45:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8A7CA8700F6; Tue, 31 May 2011 22:45:40 +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 78D2Sa-Wn7+h; Tue, 31 May 2011 22:45:34 +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 2514D8700F5; Tue, 31 May 2011 22:45:34 +0200 (CEST)
Message-ID: <4DE5536D.9050906@globis.net>
Date: Tue, 31 May 2011 22:45:33 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Brian E Carpenter ,  ipng@69706e6720323030352d30312d31340a.nosense.org
Subject: Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]
References: <4DE3F87A.5060502@globis.net> <4DE40821.9030205@gmail.com> <4DE420E2.6010207@globis.net>
In-Reply-To: <4DE420E2.6010207@globis.net>
Content-Type: multipart/alternative; boundary="------------010701090504010005040108"
Cc: Thomas Narten , ipv6@ietf.org, Ralph Droms 
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, 31 May 2011 20:45:46 -0000

This is a multi-part message in MIME format.
--------------010701090504010005040108
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Ray Hunter wrote:
> It's definitely going to become an operational FAQ, unless it is very 
> clear whether/how a network operator can force equivalent use of 
> DHCPv4 static address assignment for both source and destination 
> addresses via DHCPv6 (possibly by turning off SLAAC for assignment of 
> GUA on an interface via a flag, or via RFC3484 bis), and how to 
> achieve this effect for all nodes on a link, without resorting to 
> local configuration. So I may as well the first to ask.

In the absence of other answers, here's my analysis and "how to achieve 
current semi backward-compatible DHCPv4 like behavior in DHCPv6".

Conclusion: it does not see to be very straightforward IMVVHO.
[note: not in any way a flame, just an attempt at documenting a 
real-live use-case v. current implementations of current standards
The use case is based on current implementations of IETF standards in 
Windows 7 and Windows 2008. This is not a criticism of those OS'es. It's 
just a common combination already in production that people like me can 
easily relate to.]


Problem statement: a network manager wants to be able to create firewall 
rules to control access at a granularity level of an individual Windows 
7 PC communicating via IPv6 with an individual Windows Server 2008. The 
motivation is SoX / ISO27001 compliance. The manager does not want the 
firewall rules to have to change every day, and the rules should also be 
independent of the NIC related MAC/EUI-64 address so that they do not 
change upon NIC hardware replacement.


Suggested analysis & solution according to TODAY's documents:

Assumptions of today's default behavior (implementation dependent):
Both Windows 2008 & Windows 7 have IPv6 enabled by default and IPv6 is 
preferred over IPv4 (source: Understanding IPv6 2)
Windows Server 2008 auto registers SLAAC IPv6 GUA in DNS, but not 
temporary addresses. (source: Understanding IPv6 2)
DHCPv6 IPAM system will also register DHCPv6 assigned IPv6 GUA in DNS 
(source: an commercial implementation)
Windows 7 uses temporary addresses for outbound sessions by default. 
(source: Understanding IPv6 2)
Firewall only supports static filtering rules configured by the CLI. 
(source: all common implementations)
DHCPv6 will be available in every implementation (via recent upgrade to 
SHOULD in 6man-node-req-bis-10)


If a DNS server received auto-registration for both SLAAC GUA and DHCPv6 
GUA derived addresses in DNS, the manager does not want the Windows 7 
machine to connect to the SLAAC generated GUA e.g. 
2001:4f0:df8c:2:021c:c0ff:fee2:84e4 instead of the DHCPv6 obtained GUA 
e.g. 2001:47f0:df8c:2::2 because only the DHCPv6 GUA 2001:47f0:df8c:2::2 
will have a firewall rule entry.

Equally it is more than likely that there will be no firewall rule to 
allow RFC 3041 temporary addresses from the Windows 7 PC source address, 
so any session attempts to connect from a source using a temporary 
address will also fail.


After doing my own research, I think the answer today to achieve desired 
semi-backwards compatible DHCPv4 like behavior is:

RFC3484 prefix policy table is required to determine source and 
destination address preference if there are both DHCPv6 GUA & SLAAC GUA 
configured on the same node at the same precedence in the prefix policy 
table.

RFC3484 & RFC3484 bis currently have no mechanism to achieve preference 
of DHCPv6 GUA over a SLAAC GUA on the same prefix, so the manager 
currently needs to stop both nodes obtaining a SLAAC derived GUA in the 
first place, otherwise behavior is unpredictable [no tie break in 
RFC3484 or RFC3484 bis].

Any RFC 3041 temporary addresses that are used by a client or server on 
outbound sessions (Windows default) would also probably get blocked by a 
host to server firewall rule. So the manager needs to turn off the 
feature of using temporary addresses by default on every server and 
every host system [no IETF mechanism to do this, so this is local 
configuration via Active Directory or via a netsh command: netsh 
interface ipv6 set global randomizeidentifiers=disabled].


Now the router:
DHCPv6 relay =ENABLED, and manually configured pointed at a central 
DHCPv6 server

RA = ENABLED because it is needed for the default route on both Windows 
machines
source http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-10
 > Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 
are expected to determine their default router information and on-link 
prefix information from received Router Advertisements.

RA has to include all the DHCPv6 valid prefixes as RA options for on 
line / off link determination
source RFC 4861
 > A router SHOULD include all its on-link prefixes (except the 
link-local prefix) so that multihomed hosts have complete prefix  
information about on-link destinations for the links to which they attach.

RA has to be configured to set the A flag = OFF for ALL prefixes on this 
router interface (autonomous address-configuration flag)
source RFC4682
 > If the Autonomous flag is not set, silently ignore the Prefix 
Information option.

M (managed) flag = ON -> indicate presence of DHCPv6 and desire to use it
source RFC4681
 > When set, it indicates that addresses are available via Dynamic Host 
Configuration Protocol [DHCPv6].

O (Other) flag = X -> irrelevant
source RFC4681
 > If the M flag is set, the O flag is redundant and can be ignored 
because DHCPv6 will return all available configuration information.


You may ask "how is this different from IPv4 today at an operational/ 
implementation level?"

IMVHO [this is not a flame! just an attempt at a neutral analysis from 
an existing enterprise network based implementation]
We have no temporary IPv4 addresses to override by default
We have no SLAAC equivalent in IPv4 to turn off
By default nodes generally use DHCPv4 + broadcast on link connection 
(hard coded default in almost every OS but which can be overridden)
Default router is generally learned via DHCPv4 in an existing tool
We generally only have one IPv4 address that is auto-registered in DNS 
per adapter
We have no address selection issues (there's only 1 source and 1 
destination address)
DHCPv4 server or DHCPv4 relay is built into almost every implementation 
even though it was hardly formally standardized

regards,
RayH


--------------010701090504010005040108
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit




  


Ray Hunter wrote:


  
It's definitely going to become
an operational FAQ, unless it is very clear whether/how a network
operator can force equivalent use of DHCPv4 static address assignment
for both source and destination addresses via DHCPv6 (possibly by
turning off SLAAC for assignment of GUA on an interface via a flag, or
via RFC3484 bis), and how to achieve this effect for all nodes on a
link, without resorting to local configuration. So I may as well the
first to ask.





In the absence of other answers, here's my analysis and "how to achieve
current semi backward-compatible DHCPv4 like behavior in DHCPv6".



Conclusion: it does not see to be very straightforward IMVVHO.

[note: not in any way a flame, just an attempt at documenting a
real-live use-case v. current implementations of current standards

The use case is based on current implementations of IETF standards in
Windows 7 and Windows 2008. This is not a criticism of those OS'es.
It's just a common combination already in production that people like
me can easily relate to.]





Problem statement: a network manager wants to be able to create
firewall rules to control access at a granularity level of an
individual Windows 7 PC
communicating via IPv6 with an individual Windows Server 2008. The
motivation is SoX / ISO27001 compliance. The manager does not want the
firewall rules to have to change
every day, and the rules should also be independent of the NIC related
MAC/EUI-64 address so that they do not change upon NIC hardware
replacement.





Suggested analysis & solution according to TODAY's documents:



Assumptions of today's default behavior (implementation dependent):

Both Windows 2008 & Windows 7 have IPv6 enabled by default and IPv6
is preferred over IPv4 (source:
Understanding IPv6 2)

Windows Server 2008 auto registers SLAAC IPv6 GUA in DNS, but not
temporary addresses. (source:
Understanding IPv6 2)

DHCPv6 IPAM system will also register DHCPv6 assigned IPv6 GUA in DNS
(source: an commercial implementation)

Windows 7 uses temporary addresses for outbound sessions by default.
(source: Understanding IPv6 2)

Firewall only supports static filtering rules configured by the CLI.
(source: all common implementations)

DHCPv6 will be available in every implementation (via recent upgrade to
SHOULD in 6man-node-req-bis-10)





If a DNS server received auto-registration for both SLAAC GUA and
DHCPv6 GUA derived addresses in DNS, the
manager does not want the Windows 7 machine to connect to the SLAAC
generated GUA e.g. 2001:4f0:df8c:2:021c:c0ff:fee2:84e4 instead of the
DHCPv6
obtained GUA e.g. 2001:47f0:df8c:2::2 because only the DHCPv6 GUA
2001:47f0:df8c:2::2 will
have a firewall rule entry.



Equally it is more than likely that there will be no firewall rule to
allow RFC 3041 temporary addresses
from the Windows 7 PC source address, so any session attempts to
connect from a
source using a temporary address will also fail.





After doing my own research, I think the answer today to achieve
desired semi-backwards compatible DHCPv4 like behavior is:



RFC3484 prefix policy table is required to determine source and
destination address preference if there are both DHCPv6 GUA & SLAAC
GUA configured on the same node at the same precedence in the
prefix policy table.



RFC3484 & RFC3484 bis currently have no mechanism to achieve
preference of DHCPv6 GUA over a SLAAC GUA on the same prefix, so the
manager currently needs to stop
both nodes obtaining a SLAAC derived GUA in the first place, otherwise
behavior is unpredictable [no tie break in RFC3484 or RFC3484 bis].



Any RFC 3041 temporary addresses that are used by a client or server on
outbound sessions (Windows default) would also probably get blocked by
a host to server firewall rule. So the manager needs to turn off the
feature of using temporary addresses by default on every server and
every host system [no IETF mechanism to do this, so this is local
configuration via Active Directory or via a netsh command: netsh
interface ipv6 set global randomizeidentifiers=disabled].





Now the router:

DHCPv6 relay =ENABLED, and manually configured pointed at a central
DHCPv6 server



RA = ENABLED because it is needed for the default route on both Windows
machines

source http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-10

> Nodes using the Dynamic Host Configuration Protocol for IPv6
(DHCPv6) are expected to determine their default router information and
on-link prefix information from received Router Advertisements.



RA has to include all the DHCPv6 valid prefixes as RA options for on
line /
off link determination

source RFC 4861

> A router SHOULD include all its on-link prefixes (except the
link-local prefix) so that multihomed hosts have complete prefix 
information about on-link destinations for the links to which they
attach. 



RA has to be configured to set the A flag = OFF for ALL prefixes on
this router
interface (autonomous address-configuration flag)

source RFC4682

> If the Autonomous flag is not set, silently ignore the Prefix
Information option.



M (managed) flag = ON -> indicate presence of DHCPv6 and desire to
use it

source RFC4681

> When set, it indicates that addresses are available via Dynamic
Host Configuration Protocol [DHCPv6].



O (Other) flag = X -> irrelevant

source RFC4681

> If the M flag is set, the O flag is redundant and can be ignored
because DHCPv6 will return all available configuration information.





You may ask "how is this different from IPv4 today at an operational/
implementation level?"



IMVHO [this is not a flame! just an attempt at a neutral analysis from
an existing enterprise network based implementation]

We have no temporary IPv4 addresses to override by default

We have no SLAAC equivalent in IPv4 to turn off

By default nodes generally use DHCPv4 + broadcast on link connection
(hard coded default in almost every OS but which can be overridden)

Default router is generally learned via DHCPv4 in an existing tool

We generally only have one IPv4 address that is auto-registered in DNS
per adapter

We have no address selection issues (there's only 1 source and 1
destination address)

DHCPv4 server or DHCPv4 relay is built into almost every implementation
even though it was hardly formally standardized



regards,

RayH






--------------010701090504010005040108--

From v6ops@globis.net  Tue May 31 13:52:18 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 0D8FCE07C0 for ; Tue, 31 May 2011 13:52:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.216
X-Spam-Level: 
X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_22=0.6]
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 8mXQTcjALoQY for ; Tue, 31 May 2011 13:52:17 -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 768FDE070B for ; Tue, 31 May 2011 13:52:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6C4248700F6; Tue, 31 May 2011 22:52:15 +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 L2O8ZtgIjvuN; Tue, 31 May 2011 22:52:09 +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 656F48700F5; Tue, 31 May 2011 22:52:09 +0200 (CEST)
Message-ID: <4DE554F9.20603@globis.net>
Date: Tue, 31 May 2011 22:52:09 +0200
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Brian E Carpenter ,  ipng@69706e6720323030352d30312d31340a.nosense.org
Subject: Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]
References: <4DE3F87A.5060502@globis.net> <4DE40821.9030205@gmail.com> <4DE420E2.6010207@globis.net> <4DE5536D.9050906@globis.net>
In-Reply-To: <4DE5536D.9050906@globis.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Thomas Narten , ipv6@ietf.org, Ralph Droms 
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, 31 May 2011 20:52:18 -0000

Sorry a couple of important typos on RFC numbers: email escaped too early.
Disregard previous message, and use this one.

Ray Hunter wrote:
> It's definitely going to become an operational FAQ, unless it is very 
> clear whether/how a network operator can force equivalent use of 
> DHCPv4 static address assignment for both source and destination 
> addresses via DHCPv6 (possibly by turning off SLAAC for assignment of 
> GUA on an interface via a flag, or via RFC3484 bis), and how to 
> achieve this effect for all nodes on a link, without resorting to 
> local configuration. So I may as well be the first to ask.

In the absence of other answers, here's my analysis and "how to achieve 
current semi backward-compatible DHCPv4 like behavior in DHCPv6".

Conclusion: it does not see to be very straightforward IMVVHO.
[note: not in any way a flame, just an attempt at documenting a 
real-live use-case v. current implementations of current standards
The use case is based on current implementations of IETF standards in 
Windows 7 and Windows 2008. This is not a criticism of those OS'es. It's 
just a common combination already in production that people like me can 
easily relate to.]


Problem statement: a network manager wants to be able to create firewall 
rules to control access at a granularity level of an individual Windows 
7 PC communicating via IPv6 with an individual Windows Server 2008. The 
motivation is SoX / ISO27001 compliance. The manager does not want the 
firewall rules to have to change every day, and the rules should also be 
independent of the NIC related MAC/EUI-64 address so that they do not 
change upon NIC hardware replacement.


Suggested analysis & solution according to TODAY's documents:

Assumptions of today's default behavior (implementation dependent):
Both Windows 2008 & Windows 7 have IPv6 enabled by default and IPv6 is 
preferred over IPv4 (source: Understanding IPv6 2)
Windows Server 2008 auto registers SLAAC IPv6 GUA in DNS, but not 
temporary addresses. (source: Understanding IPv6 2)
DHCPv6 IPAM system will also register DHCPv6 assigned IPv6 GUA in DNS 
(source: an commercial implementation)
Windows 7 uses temporary addresses for outbound sessions by default. 
(source: Understanding IPv6 2)
Firewall only supports static filtering rules configured by the CLI. 
(source: all common implementations)
DHCPv6 will be available in every implementation (via recent upgrade to 
SHOULD in draft-ietf-6man-node-req-bis-10)


If a DNS server received auto-registration for both SLAAC GUA and DHCPv6 
GUA derived addresses in DNS, the manager does not want the Windows 7 
machine to connect to the SLAAC generated GUA e.g. 
2001:4f0:df8c:2:021c:c0ff:fee2:84e4 instead of the DHCPv6 obtained GUA 
e.g. 2001:47f0:df8c:2::2 because only the DHCPv6 GUA 2001:47f0:df8c:2::2 
will have a firewall rule entry.

Equally it is more than likely that there will be no firewall rule to 
allow RFC 3041 temporary addresses from the Windows 7 PC source address, 
so any session attempts to connect from a source using a temporary 
address will also fail.


After doing my own research, I think the answer today to achieve desired 
semi-backwards compatible DHCPv4 like behavior is:

RFC3484 prefix policy table is required to determine source and 
destination address preference if there are both DHCPv6 GUA & SLAAC GUA 
configured on the same node at the same precedence in the prefix policy 
table.

RFC3484 & RFC3484 bis currently have no mechanism to achieve preference 
of DHCPv6 GUA over a SLAAC GUA on the same prefix, so the manager 
currently needs to stop both nodes obtaining a SLAAC derived GUA in the 
first place, otherwise behavior is unpredictable [no tie break in 
RFC3484 or RFC3484 bis].

Any RFC 3041 temporary addresses that are used by a client or server on 
outbound sessions (Windows default) would also probably get blocked by a 
host to server firewall rule. So the manager needs to turn off the 
feature of using temporary addresses by default on every server and 
every host system [no IETF mechanism to do this, so this is local 
configuration via Active Directory or via a netsh command: netsh 
interface ipv6 set global randomizeidentifiers=disabled].


Now the router:
DHCPv6 relay =ENABLED, and manually configured pointed at a central 
DHCPv6 server

RA = ENABLED because it is needed for the default route on both Windows 
machines
source http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-10
 > Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 
are expected to determine their default router information and on-link 
prefix information from received Router Advertisements.

RA has to include all the DHCPv6 valid prefixes as RA options for on 
link / off link determination
source RFC 4861
 > A router SHOULD include all its on-link prefixes (except the 
link-local prefix) so that multihomed hosts have complete prefix  
information about on-link destinations for the links to which they attach.

RA has to be configured to set the A flag = OFF for ALL prefixes on this 
router interface (autonomous address-configuration flag)
source RFC4862
 > If the Autonomous flag is not set, silently ignore the Prefix 
Information option.

M (managed) flag = ON -> indicate presence of DHCPv6 and desire to use it
source RFC4861
 > When set, it indicates that addresses are available via Dynamic Host 
Configuration Protocol [DHCPv6].

O (Other) flag = X -> irrelevant
source RFC4861
 > If the M flag is set, the O flag is redundant and can be ignored 
because DHCPv6 will return all available configuration information.


You may ask "how is this different from IPv4 today at an operational/ 
implementation level?"

IMVHO [this is not a flame! just an attempt at a neutral analysis from 
an existing enterprise network based implementation]
We have no temporary IPv4 addresses to override by default
We have no SLAAC equivalent in IPv4 to turn off
By default nodes generally use DHCPv4 + broadcast on link connection 
(hard coded default in almost every OS but which can be overridden)
Default router is generally learned via DHCPv4 in an existing tool
We generally only have one IPv4 address that is auto-registered in DNS 
per adapter
We have no address selection issues (there's only 1 source and 1 
destination address)
DHCPv4 server or DHCPv4 relay is built into almost every implementation 
even though it was hardly formally standardized

regards,
RayH

From fernando.gont.netbook.win@gmail.com  Tue May 31 13:59:38 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 6AA02E08AE for ; Tue, 31 May 2011 13:59:38 -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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
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 Gck8endjBuyt for ; Tue, 31 May 2011 13:59:38 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D3F95E08F1 for ; Tue, 31 May 2011 13:59:37 -0700 (PDT)
Received: by gwb20 with SMTP id 20so2665354gwb.31 for ; Tue, 31 May 2011 13:59:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=2z5mkEgFPKXSEPep3ayRp7wdt/LYdQqnPHgZOgvL7ys=; b=eeblRQNIK0P1GziggiQz3dCkpj4r1QhE+666kgw2fWVdIwjQi8SRQlrlnh7lWM/sL5 mG73CUyJ0YdXL6FrT3avxG7zr4e0YArBY1fbOk9TU0Qp03QMbc9jU5W7/8uJ5/X6Wzsx EDs+I0Um6hVpxPBJGAxfaLb5fsTaAcnxH+WyU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=KG+NHNYuVqfR3kyjHNsm95haQJBZKThdzuiPP1cQRYHK8aiu/WMr/VQn6WzqxB12Hp 4GbEabsfkmWOlczQzZacRA8t4q6bXBCVG8U2V9yLRKbnHytF0ASewXoAvvHqvGyQc7v6 /Q7sQ+svTWmkbrQGHMblqK+OqBMo22TaCMG10=
Received: by 10.91.126.12 with SMTP id d12mr5384088agn.98.1306875577219; Tue, 31 May 2011 13:59:37 -0700 (PDT)
Received: from [192.168.0.114] ([190.190.97.123]) by mx.google.com with ESMTPS id w19sm267894anf.38.2011.05.31.13.59.31 (version=SSLv3 cipher=OTHER); Tue, 31 May 2011 13:59:36 -0700 (PDT)
Sender: Fernando Gont 
Message-ID: <4DE556A9.2050702@gont.com.ar>
Date: Tue, 31 May 2011 17:59:21 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
MIME-Version: 1.0
To: "ipv6@ietf.org" 
Subject: New I-D: Neighbor Discovery and IPv6 Extension Headers (draft-gont-6man-nd-extension-headers)
X-Enigmail-Version: 1.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: Tue, 31 May 2011 20:59:38 -0000

Folks,

I have just published a new Internet-Draft
(draft-gont-6man-nd-extension-headers) entitled "Security Implications
of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery".

The I-D is available at:
http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-00.txt

The Abstract of the I-D is:
---- cut here ----
   IPv6 Extension Headers with Neighbor Discovery messages can be
   leveraged to circumvent simple local network protections, such as
   "Router Advertisement Guard".  Since there is no legitimate use for
   IPv6 Extension Headers in Neighbor Discovery messages, and such use
   greatly complicates network monitoring and simple security
   mitigations such as RA-Guard, this document proposes that hosts
   silently ignore Neighbor Discovery messages that use IPv6 Extension
   Headers.
---- cut here ----

Note: A closely related (and just published) I-D is
draft-gont-v6ops-ra-guard-evasion-00, which is aimed at the v6ops wg
(rather than 6man).

Any comments on any of these I-Ds will be very welcome.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From brian.e.carpenter@gmail.com  Tue May 31 14:05:42 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 35F14E08F4 for ; Tue, 31 May 2011 14:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.999
X-Spam-Level: 
X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 kebcACqPDjmu for ; Tue, 31 May 2011 14:05:41 -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 F3D9DE08F8 for ; Tue, 31 May 2011 14:05:40 -0700 (PDT)
Received: by bwz13 with SMTP id 13so4652796bwz.31 for ; Tue, 31 May 2011 14:05:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ymc6BdnwV3pWgDRbZ40bRhFrAzzc1z5XrEL1cW6OBsE=; b=ECtWMujJPGvmZ7nHAkERwA8iycFBVYJmuuYTJMZaP9smZwJePHFYik2EXaWcfkE8qs Bcn4hs+gxkAlLh6llutU7NpHTxdKUpCzvhBWxwTfRIv6An+2S3tRaJZ/k+bkEPhWmfr4 aTheJV9ilxMWc7grW+LMXwBBxCpX3xo5Dw08Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=W32dreDmGYdGYx2pXzLlvzGOC2TXQ6el6QzKtkh+/Aoj0yaXslchMYXX7ck4+mJhHy m1/unSersTjHZ+Sq7Giy7d6Dw+tc1xl31u0JnX2zekXtQ/w4O4NmuvrzwMoaeG8i0mDC 5gNQDXNW1g0kJODZX4xdhNVqaoj6DiS+UGjQ4=
Received: by 10.204.20.147 with SMTP id f19mr5867479bkb.163.1306875939844; Tue, 31 May 2011 14:05:39 -0700 (PDT)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id l24sm337017bkw.15.2011.05.31.14.05.33 (version=SSLv3 cipher=OTHER); Tue, 31 May 2011 14:05:38 -0700 (PDT)
Message-ID: <4DE55815.3080702@gmail.com>
Date: Wed, 01 Jun 2011 09:05:25 +1200
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ray Hunter 
Subject: Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]
References: <4DE3F87A.5060502@globis.net> <4DE40821.9030205@gmail.com> <4DE420E2.6010207@globis.net> <4DE5536D.9050906@globis.net> <4DE554F9.20603@globis.net>
In-Reply-To: <4DE554F9.20603@globis.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: ipv6@ietf.org, Ralph Droms , Thomas Narten 
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, 31 May 2011 21:05:42 -0000

Ray,

Without going into details: how about turning this into
draft-hunter-v6ops-something and having the debate over in v6ops?

I think that would be useful, personally.

Regards
   Brian

On 2011-06-01 08:52, Ray Hunter wrote:
> Sorry a couple of important typos on RFC numbers: email escaped too early.
> Disregard previous message, and use this one.
> 
> Ray Hunter wrote:
>> It's definitely going to become an operational FAQ, unless it is very
>> clear whether/how a network operator can force equivalent use of
>> DHCPv4 static address assignment for both source and destination
>> addresses via DHCPv6 (possibly by turning off SLAAC for assignment of
>> GUA on an interface via a flag, or via RFC3484 bis), and how to
>> achieve this effect for all nodes on a link, without resorting to
>> local configuration. So I may as well be the first to ask.
> 
> In the absence of other answers, here's my analysis and "how to achieve
> current semi backward-compatible DHCPv4 like behavior in DHCPv6".
> 
> Conclusion: it does not see to be very straightforward IMVVHO.
> [note: not in any way a flame, just an attempt at documenting a
> real-live use-case v. current implementations of current standards
> The use case is based on current implementations of IETF standards in
> Windows 7 and Windows 2008. This is not a criticism of those OS'es. It's
> just a common combination already in production that people like me can
> easily relate to.]
> 
> 
> Problem statement: a network manager wants to be able to create firewall
> rules to control access at a granularity level of an individual Windows
> 7 PC communicating via IPv6 with an individual Windows Server 2008. The
> motivation is SoX / ISO27001 compliance. The manager does not want the
> firewall rules to have to change every day, and the rules should also be
> independent of the NIC related MAC/EUI-64 address so that they do not
> change upon NIC hardware replacement.
> 
> 
> Suggested analysis & solution according to TODAY's documents:
> 
> Assumptions of today's default behavior (implementation dependent):
> Both Windows 2008 & Windows 7 have IPv6 enabled by default and IPv6 is
> preferred over IPv4 (source: Understanding IPv6 2)
> Windows Server 2008 auto registers SLAAC IPv6 GUA in DNS, but not
> temporary addresses. (source: Understanding IPv6 2)
> DHCPv6 IPAM system will also register DHCPv6 assigned IPv6 GUA in DNS
> (source: an commercial implementation)
> Windows 7 uses temporary addresses for outbound sessions by default.
> (source: Understanding IPv6 2)
> Firewall only supports static filtering rules configured by the CLI.
> (source: all common implementations)
> DHCPv6 will be available in every implementation (via recent upgrade to
> SHOULD in draft-ietf-6man-node-req-bis-10)
> 
> 
> If a DNS server received auto-registration for both SLAAC GUA and DHCPv6
> GUA derived addresses in DNS, the manager does not want the Windows 7
> machine to connect to the SLAAC generated GUA e.g.
> 2001:4f0:df8c:2:021c:c0ff:fee2:84e4 instead of the DHCPv6 obtained GUA
> e.g. 2001:47f0:df8c:2::2 because only the DHCPv6 GUA 2001:47f0:df8c:2::2
> will have a firewall rule entry.
> 
> Equally it is more than likely that there will be no firewall rule to
> allow RFC 3041 temporary addresses from the Windows 7 PC source address,
> so any session attempts to connect from a source using a temporary
> address will also fail.
> 
> 
> After doing my own research, I think the answer today to achieve desired
> semi-backwards compatible DHCPv4 like behavior is:
> 
> RFC3484 prefix policy table is required to determine source and
> destination address preference if there are both DHCPv6 GUA & SLAAC GUA
> configured on the same node at the same precedence in the prefix policy
> table.
> 
> RFC3484 & RFC3484 bis currently have no mechanism to achieve preference
> of DHCPv6 GUA over a SLAAC GUA on the same prefix, so the manager
> currently needs to stop both nodes obtaining a SLAAC derived GUA in the
> first place, otherwise behavior is unpredictable [no tie break in
> RFC3484 or RFC3484 bis].
> 
> Any RFC 3041 temporary addresses that are used by a client or server on
> outbound sessions (Windows default) would also probably get blocked by a
> host to server firewall rule. So the manager needs to turn off the
> feature of using temporary addresses by default on every server and
> every host system [no IETF mechanism to do this, so this is local
> configuration via Active Directory or via a netsh command: netsh
> interface ipv6 set global randomizeidentifiers=disabled].
> 
> 
> Now the router:
> DHCPv6 relay =ENABLED, and manually configured pointed at a central
> DHCPv6 server
> 
> RA = ENABLED because it is needed for the default route on both Windows
> machines
> source http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-10
>> Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
> are expected to determine their default router information and on-link
> prefix information from received Router Advertisements.
> 
> RA has to include all the DHCPv6 valid prefixes as RA options for on
> link / off link determination
> source RFC 4861
>> A router SHOULD include all its on-link prefixes (except the
> link-local prefix) so that multihomed hosts have complete prefix 
> information about on-link destinations for the links to which they attach.
> 
> RA has to be configured to set the A flag = OFF for ALL prefixes on this
> router interface (autonomous address-configuration flag)
> source RFC4862
>> If the Autonomous flag is not set, silently ignore the Prefix
> Information option.
> 
> M (managed) flag = ON -> indicate presence of DHCPv6 and desire to use it
> source RFC4861
>> When set, it indicates that addresses are available via Dynamic Host
> Configuration Protocol [DHCPv6].
> 
> O (Other) flag = X -> irrelevant
> source RFC4861
>> If the M flag is set, the O flag is redundant and can be ignored
> because DHCPv6 will return all available configuration information.
> 
> 
> You may ask "how is this different from IPv4 today at an operational/
> implementation level?"
> 
> IMVHO [this is not a flame! just an attempt at a neutral analysis from
> an existing enterprise network based implementation]
> We have no temporary IPv4 addresses to override by default
> We have no SLAAC equivalent in IPv4 to turn off
> By default nodes generally use DHCPv4 + broadcast on link connection
> (hard coded default in almost every OS but which can be overridden)
> Default router is generally learned via DHCPv4 in an existing tool
> We generally only have one IPv4 address that is auto-registered in DNS
> per adapter
> We have no address selection issues (there's only 1 source and 1
> destination address)
> DHCPv4 server or DHCPv4 relay is built into almost every implementation
> even though it was hardly formally standardized
> 
> regards,
> RayH
> 

From rdroms.ietf@gmail.com  Tue May 31 14:32: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 A7285E07D5 for ; Tue, 31 May 2011 14:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.999
X-Spam-Level: 
X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 m+nCPOtPm-5X for ; Tue, 31 May 2011 14:32:44 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7975EE0726 for ; Tue, 31 May 2011 14:32:44 -0700 (PDT)
Received: by qwc23 with SMTP id 23so3160894qwc.31 for ; Tue, 31 May 2011 14:32:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=wHj5COBCTaZ5QasdVts5beps19axhJi3cOBnSvSLtTI=; b=FVysGOq0FgLEGyre1dngXIWpRmcAbZ5GGNWpIzoekgX/Tz0IhI7E9+qDalzEkveBj8 ESeWf8HLP2A8MUd3mj/KElHRx2NSeE+auN00MvIp3XPiXq9VcY8HlNrk7qFQL3OXnxVe 7jVkd+jt2LVrPR3r7t78e8Qm3xFqvIwTI6SY4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=wPRYFXXnBrYHz8fEKO5B2oA90LBP4mvX+Q+n4HpgihhgaEdyuN8rLQPgXi+RKVQ4Kw RRVrT8A8LsHB3Ilk21Kqmtq5cQQWgXNGDTQoiYtdFsVJKZPNt8i7dynEs3DkqziD2cHh nIlz/8fcLbmUDlarJeJMsOk41mD4QB3vfzjgU=
Received: by 10.224.217.135 with SMTP id hm7mr4806388qab.232.1306877561979; Tue, 31 May 2011 14:32:41 -0700 (PDT)
Received: from bxb-rdroms-8711.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id g1sm280112qck.32.2011.05.31.14.32.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 14:32:41 -0700 (PDT)
Subject: Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ralph Droms 
In-Reply-To: <4BC7CABA-D871-4B27-96BA-10A2F9D6D2B1@cisco.com>
Date: Tue, 31 May 2011 17:32:37 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D170D21-6A6B-414B-A06B-6A62A4C0BF74@gmail.com>
References: <4DE3F87A.5060502@globis.net> <4DE40821.9030205@gmail.com> <4DE420E2.6010207@globis.net> <4BC7CABA-D871-4B27-96BA-10A2F9D6D2B1@cisco.com>
To: Ray Hunter 
X-Mailer: Apple Mail (2.1084)
Cc: Thomas Narten , "ipv6@ietf.org Mailing List WG" , Ralph Droms , Brian E Carpenter , Fred Baker 
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, 31 May 2011 21:32:45 -0000

On May 30, 2011, at 10:38 PM 5/30/11, Fred Baker wrote:

>=20
> On May 30, 2011, at 3:57 PM, Ray Hunter wrote:
>=20
>> This is danger of going off topic I know (maybe it should go in =
v6ops), but it's important to me to be able to understand the =
consequences of the discussion, so please bear with me. It's definitely =
going to become an operational FAQ, unless it is very clear whether/how =
a network operator can force equivalent use of DHCPv4 static address =
assignment for both source and destination addresses via DHCPv6 =
(possibly by turning off SLAAC for assignment of GUA on an interface via =
a flag, or via RFC3484 bis), and how to achieve this effect for all =
nodes on a link, without resorting to local configuration. So I may as =
well the first to ask.
>=20
> link-local will use SLAAC no matter what. It just does.
>=20
> I'll let Ralph or one of the other RFC 3315 authors comment on DHCPv6, =
as they knows a lot more about it than I.=20

Use of SLAAC is controlled by the A bit in the Prefix Information =
option.  If the A bit is zero, the host will not configure an address on =
the receiving interface using SLAAC. =20

The M bit in an RA gives a hint that DHCPv6 service is available.  The =
host behavior is not entirely controlled by the M bit; a host can choose =
to run DHCPv6 independent of the setting of the M bit.  A reasonable =
host might not bother with DHCPv6 if the M bit is 0; at the same time, a =
reasonable host might go ahead with DHCPv6 if it doesn't receive any =
Prefix Information options with the A bit set to one.

- Ralph

>=20
> I would expect, however, that the use of DHCP is something configured =
on the system in question, just like it is in IPv4. Not that there is an =
auto-configure option in IPv4 - the other alternative is manual =
configuration, and most systems come with DHCP configured as the =
default. IPv6 systems come, at least today, with SLAAC as the default. =
So there is a requirement to configure DHCPv6, at least from that =
perspective. That said, SLAAC ain't gonna happen in the absence of RAs, =
and you can disable RAs on the router. So if an interface comes up and =
no RA is forthcoming, I could imagine the thing probing with a DHCPv6 =
request.
>=20
>> Brian E Carpenter wrote:
>>> Ray,
>>>=20
>>> On 2011-05-31 08:05, Ray Hunter wrote:
>>> ...
>>>=20
>>>=20
>>>> Which source address (SLAAC/DHCPv6) would be used by the client for =
an
>>>> outbound session if a SLAAC address and a DHCPv6 were both =
configured on
>>>> the same link and with the same prefix, in the absence of a flag?=20=

>>>>=20
>>>>=20
>>>=20
>>> Whichever RFC3484bis or the local policy table determines;
>>> this is orthogonal to the question of where the addresses come from.
>>>=20
>>>=20
>>>=20
>> Hmm. That's the conclusion I also came to myself already if there =
were no flags.
>>=20
>> So how would you prefer DHCPv6 (centrally) assigned addresses as =
opposed to SLAAC EUI64 addresses derived from MAC BIA ?
>>=20
>> Is this still an open issue, and I should just be patient?
>>=20
>> Would you have to set a prefix for every single DHCP range in =
RFC3484, and make sure the DHCPv6 assigned range did not overlap with =
likely EUI64 derived addresses to be able to guarantee that the DHCPv6 =
assigned address will be preferred?
>>=20
>> Or would you have to double the amount of entries in the ACL for both =
the DHCPv6 address and the SLAAC address (coded to MAC address)
>>=20
>> Or will RFC3484 bis be updated to include this behavior by =
automatically guessing which addresses are SLAAC addresses and which are =
DHCPv6 addresses and allow users to prefer DHCPv6 addresses?=20
>>=20
>> Bearing in mind destination address selection is also affected, so it =
might have to be able to remotely 'guess' what is a SLAAC address versus =
a DHCPv6 assigned address. [I checked the RFC 3484 bis list and there is =
no text today in version 02 =
http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-02 nor =
anything proposed to cover this case in emails]
>>=20
>> see http://www.ietf.org/mail-archive/web/ipv6/current/msg13878.html =
for the last note.
>>=20
>>> I'll send a query to the ipv6-ops list just to see if this is a =
common expectation.
>>=20
>> The answer to the operational question: Yes IMHO there is a very =
clear operational expectation of being able to easily achieve DHCPv4 =
like behavior using DHCPv6, and this is hot operational topic.
>>=20
>> Some people have 50000 rules in their firewalls today. They won't =
thank anyone for 100K rules (to support both SLAAC+DHCPv6), or 50K rules =
that may change every time a NIC card fails (SLAAC only).
>>=20
>>=20
>>>> Think
>>>> dynamic DNS too: which (destination) address(es) would be auto
>>>> registered at the server end?
>>>>=20
>>>>=20
>>>=20
>>> Both, if it's a server and you've chosen to use dynamic address
>>> allocation for servers. Again, this is orthogonal to where
>>> the addresses come from. It's going to be SOP for servers with
>>> multiple addresses.
>>>=20
>>>=20
>>>=20
>> 
>>>=20
>>> Yes, there are lots of bad habits that have grown up over the years
>>> that IPv6 challenges. For example, setting the DSCP *as a function =
of
>>> the source address* makes me cringe. We're going to have to get used =
to
>>> the fact that IP addresses are not constants.
>>>=20
>>>    Brian
>>>=20
>>>=20
>>>=20
>> In the meantime, we have to continue to operate networks whilst =
transitioning.
>>=20
>> As I asked, regardless of whether we think it's good or bad practice, =
I can assure you that it's certainly _common_ practice. Pretty much =
everyone I know who implements MPLS DSCP based QoS networks does it via =
IP based ACL's to overwrite DSCP on network ingress.
>>=20
>> offtopic: on the longer term, please give us some alternatives to =
manage and signal identities and QoS policies that are widely =
implemented by all manufacturers and all network providers. No 2 MPLS =
networks I know of use the same DSCP settings. Applications generally =
only set DSCP=3D EF on voice traffic. Everything else you have no =
standard signaling mechanism. It's rare for two OS'es to behave exactly =
the same way today. Same with 2 applications. In the absence of anything =
better, people get stuck on the lowest common denominator (IP address) =
and network ingress re-writing.
>>=20
>> Anyway for some operations it really isn't so bad: think of a few =
traveling VIP users who need a bit better service without spending a =
fortune on 802.1X or additional fancy multi-SSID wireless VLANs. Think =
well managed server farm and private network where there's a bulk back =
up server (all traffic placed in D3 class) next to an interactive =
software licence in server (all traffic placed in D1 class) and the rest =
of the traffic in D2. These guys are sometimes more worried about pure =
performance and cost and ease of management, rather than theft of =
service, re-writing apps etc. etc.
>>=20
>> Not necessarily nice. But operational reality.
>>=20
>> regards,
>> RayH
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>=20


From ipng@69706e6720323030352d30312d31340a.nosense.org  Tue May 31 15:41:31 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 A13A3E07B9 for ; Tue, 31 May 2011 15:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level: 
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
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 rxcDWfAV7QZL for ; Tue, 31 May 2011 15:41:31 -0700 (PDT)
Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by ietfa.amsl.com (Postfix) with ESMTP id AC78DE0751 for ; Tue, 31 May 2011 15:41:30 -0700 (PDT)
Received: from 219-90-148-106.ip.adam.com.au ([219.90.148.106] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1QRXcv-0005g1-5v; Wed, 01 Jun 2011 08:11:29 +0930
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id CCF673B338; Wed,  1 Jun 2011 08:11:28 +0930 (CST)
Date: Wed, 1 Jun 2011 08:11:27 +0930
From: Mark Smith 
To: james woodyatt 
Subject: Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]
Message-ID: <20110601081127.73023eda@opy.nosense.org>
In-Reply-To: 
References: <4DE3F87A.5060502@globis.net> <4DE40821.9030205@gmail.com> <4DE420E2.6010207@globis.net> <4BC7CABA-D871-4B27-96BA-10A2F9D6D2B1@cisco.com> 
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.4; 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: 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: Tue, 31 May 2011 22:41:31 -0000

On Tue, 31 May 2011 09:24:19 -0700
james woodyatt  wrote:

> On May 30, 2011, at 7:38 PM, Fred Baker wrote:
> > 
> > [...] IPv6 systems come, at least today, with SLAAC as the default. So there is a requirement to configure DHCPv6, at least from that perspective. That said, SLAAC ain't gonna happen in the absence of RAs, and you can disable RAs on the router. So if an interface comes up and no RA is forthcoming, I could imagine the thing probing with a DHCPv6 request. [...]
> 
> For what it's worth, the behavior of Apple's iOS 4.3 and later is straightforward.  If there is no RA, then there is no IPv6.  iOS 4.3 doesn't support manual IPv6 configuration, so automatic configuration is the only way to plumb it.  The DHCPv6 client only starts if the router indicates availability with O=1.  Remember when I was complaining that we needed RFC 6106 for the O=0 case?  Given that we have that, I don't see any benefit to starting the DHCPv6 client unless a router explicitly tells us to expect service.  No router?  No need for dynamic host configuration.
> 

Actually, that raises an interesting question. If SLAAC and DHCPv6 were
enabled by default, ignoring the M and O bits, what type of DHCPv6 is
enabled - stateless or stateful? 

I'm sure people are expecting stateful, so the DHCPv6 client would
initially issue a Solicit and including IA_NA and IA_TA options. My
understanding is that if a DHCPv6 server won't ever provide any
addresses (as it is a "stateless" server), it is to ignore those Solicit
messages. Since the end-node may have also acquired addresses via
SLAAC, it eventually wouldn't care. However, it would have to timeout
the Solicits as per RFC3315, just in case there was a stateful DHCPv6
server available. I understand this retransimission/timeout period
is 120 seconds (SOL_MAX_RT). At that point, it should then resort to
stateless operation, using an Information-Request message, to acquire
Other DHCPv6 supplied options. So 2 minutes would need to elapse before
the client would receive options it is interested in via stateless
DHCPv6. That's an awfully long time to wait to find out other DHCPv6
option values that can't be supplied in an RA as per RFC6106.

Perhaps a stateful and stateless DHCPv6 transaction could be performed
in parallel to avoid this 2 minute delay. I think that would create
another possible conflict. What if the non-address option values that
are received via the stateless DHCPv6 transaction are different to the
non-address option values supplied by a stateful DHCPv6 server? The
current selection of either stateful or stateless DHCPv6 operation for
a segment via M&O bits, and then a DHCPv6's client's selection of a
single DHCPv6 server to continue or have a transaction with avoids
this option value mismatch ambiguity.

Regards,
Mark.


From rdroms.ietf@gmail.com  Tue May 31 17:39:13 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 B5728E06F0 for ; Tue, 31 May 2011 17:39:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nrkOMsu+OU9 for ; Tue, 31 May 2011 17:39:12 -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 6233DE06DD for ; Tue, 31 May 2011 17:39:12 -0700 (PDT)
Received: by vxg33 with SMTP id 33so5164000vxg.31 for ; Tue, 31 May 2011 17:39:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=fBJg2ST+aOAENm5JyWkqCtxNbOprDLJ+5DE9Y8TxGgs=; b=BjdAt9wSvw6mrXxOhxcEMyMvvMrOrrDY/EzmtapINT9GOsdn3m999V3wzkUzBmYLJP KBrQKZJEaRxvL4ELIr4YFhJ9MlR3Umf/IpEzCLesHXzLWVhsN9DopI40EW+TEXOLglIb Fg1cjsfyCq8axCoNwxqVH8lV6GyhhSkxmpF5I=
DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=Stfh5zq57/Ct/pqspSQHV/nubUkCBMAXhFYnUjMECcmER1xoV/GU0I8SLIQQJTB5tx y42ZIumnisB/Q6VJiGCNCzEM8AMZkhBlyhrIUG1XsGyIlkuaLYWBiJrs34O+E8LDhExb BkiWgoUkIpqD1JwWRC7/7zoKjIubz5yYag5Wk=
Received: by 10.52.98.33 with SMTP id ef1mr1270808vdb.23.1306888751737; Tue, 31 May 2011 17:39:11 -0700 (PDT)
Received: from [192.168.1.106] (c-24-62-225-5.hsd1.ma.comcast.net [24.62.225.5]) by mx.google.com with ESMTPS id j4sm277561vdu.19.2011.05.31.17.39.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 17:39:10 -0700 (PDT)
References: <4DE3F87A.5060502@globis.net> <4DE40821.9030205@gmail.com> <4DE420E2.6010207@globis.net> <4BC7CABA-D871-4B27-96BA-10A2F9D6D2B1@cisco.com>  <20110601081127.73023eda@opy.nosense.org>
In-Reply-To: <20110601081127.73023eda@opy.nosense.org>
Mime-Version: 1.0 (iPhone Mail 8J2)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <5CC88A4B-639B-4545-BCBB-CD579ED354DA@gmail.com>
X-Mailer: iPhone Mail (8J2)
From: Ralph Droms 
Subject: Re: Multiple addresses [was Node Requirements: Elevating DHCPv6 from MAY to SHOULD]
Date: Tue, 31 May 2011 20:39:06 -0400
To: Mark Smith 
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: Wed, 01 Jun 2011 00:39:13 -0000

On May 31, 2011, at 6:41 PM, Mark Smith  wrote:

> On Tue, 31 May 2011 09:24:19 -0700
> james woodyatt  wrote:
>=20
>> On May 30, 2011, at 7:38 PM, Fred Baker wrote:
>>>=20
>>> [...] IPv6 systems come, at least today, with SLAAC as the default. So t=
here is a requirement to configure DHCPv6, at least from that perspective. T=
hat said, SLAAC ain't gonna happen in the absence of RAs, and you can disabl=
e RAs on the router. So if an interface comes up and no RA is forthcoming, I=
 could imagine the thing probing with a DHCPv6 request. [...]
>>=20
>> For what it's worth, the behavior of Apple's iOS 4.3 and later is straigh=
tforward.  If there is no RA, then there is no IPv6.  iOS 4.3 doesn't suppor=
t manual IPv6 configuration, so automatic configuration is the only way to p=
lumb it.  The DHCPv6 client only starts if the router indicates availability=
 with O=3D1.  Remember when I was complaining that we needed RFC 6106 for th=
e O=3D0 case?  Given that we have that, I don't see any benefit to starting t=
he DHCPv6 client unless a router explicitly tells us to expect service.  No r=
outer?  No need for dynamic host configuration.
>>=20
>=20
> Actually, that raises an interesting question. If SLAAC and DHCPv6 were
> enabled by default, ignoring the M and O bits, what type of DHCPv6 is
> enabled - stateless or stateful?=20
>=20
> I'm sure people are expecting stateful, so the DHCPv6 client would
> initially issue a Solicit and including IA_NA and IA_TA options. My
> understanding is that if a DHCPv6 server won't ever provide any
> addresses (as it is a "stateless" server), it is to ignore those Solicit
> messages. Since the end-node may have also acquired addresses via
> SLAAC, it eventually wouldn't care. However, it would have to timeout
> the Solicits as per RFC3315, just in case there was a stateful DHCPv6
> server available. I understand this retransimission/timeout period
> is 120 seconds (SOL_MAX_RT). At that point, it should then resort to
> stateless operation, using an Information-Request message, to acquire
> Other DHCPv6 supplied options. So 2 minutes would need to elapse before
> the client would receive options it is interested in via stateless
> DHCPv6. That's an awfully long time to wait to find out other DHCPv6
> option values that can't be supplied in an RA as per RFC6106.
>=20
> Perhaps a stateful and stateless DHCPv6 transaction could be performed
> in parallel to avoid this 2 minute delay. I think that would create
> another possible conflict. What if the non-address option values that
> are received via the stateless DHCPv6 transaction are different to the
> non-address option values supplied by a stateful DHCPv6 server? The
> current selection of either stateful or stateless DHCPv6 operation for
> a segment via M&O bits, and then a DHCPv6's client's selection of a
> single DHCPv6 server to continue or have a transaction with avoids
> this option value mismatch ambiguity.
>=20
> Regards,
> Mark

Working from memory, there's an error code through which a DHCPv6 server can=
 explicitly NAK an address assigment request.

- Ralph

>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

From brian.e.carpenter@gmail.com  Tue May 31 22:13:25 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 B1725E065A for ; Tue, 31 May 2011 22:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.589
X-Spam-Level: 
X-Spam-Status: No, score=-103.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 aqkVi8hSElSz for ; Tue, 31 May 2011 22:13:25 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13E9CE0593 for ; Tue, 31 May 2011 22:13:24 -0700 (PDT)
Received: by yic13 with SMTP id 13so2825854yic.31 for ; Tue, 31 May 2011 22:13:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=6+YiHJLIhbkMF8j3BHOGy76/MpQJs27nhanXJBaKPoM=; b=srSzYClGZavCy3/8ISC8853X8UgMAE10QUUfFEPLcRvrs1LfVpj5Qb7XZ583gehGk5 z0/t7wr+efdiMFTDk5HoNThokg9vbV24BmvT1u4lrA/RcgnqSXzEer+ZcIwT4A9S6Otk ScpxNoVkwFj7QUy1CsJK1XLDHtOp6tOR6TKwg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=Uqhd72Iys7flh73q80aMu4yVSTFSfuJd26QposhM4W1toJF2HRbG2rdEjhkK+Ie7s5 RyhYlLpSIKwIsJFC58twW11J4q/Qj0+2kwgAMWUzMiWebSU+thmHqBAp2r2az7emoCVL QHwS1Lmyq31D8m+Q2VNM6D3xc2AoF/MbNkbkU=
Received: by 10.236.191.37 with SMTP id f25mr8349532yhn.441.1306905204366; Tue, 31 May 2011 22:13:24 -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 f65sm848478yhn.25.2011.05.31.22.13.23 (version=SSLv3 cipher=OTHER); Tue, 31 May 2011 22:13:24 -0700 (PDT)
Message-ID: <4DE5CA6F.6080803@gmail.com>
Date: Wed, 01 Jun 2011 17:13:19 +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: Preliminary report on flow label hash algorithms
Content-Type: text/plain; charset=UTF-8
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, 01 Jun 2011 05:13:25 -0000

In summary: the algorithm suggested in the Appendix to
draft-ietf-6man-flow-3697bis-04 doesn't perform very well
on real packets, and I have an improved version to suggest.

This doesn't affect the normative text in the draft, so I
believe it can be fixed.

The full story, with fonts, tables and pictures:

http://www.cs.auckland.ac.nz/~brian/flowhash.html

-- 
Regards
   Brian Carpenter