Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

"Mukom Akong T." <mukom.tamon@gmail.com> Sun, 08 November 2015 06:21 UTC

Return-Path: <mukom.tamon@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F1F1A6F82 for <v6ops@ietfa.amsl.com>; Sat, 7 Nov 2015 22:21:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur2TdUYgP-An for <v6ops@ietfa.amsl.com>; Sat, 7 Nov 2015 22:21:46 -0800 (PST)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203C21A6F42 for <v6ops@ietf.org>; Sat, 7 Nov 2015 22:21:46 -0800 (PST)
Received: by obctp1 with SMTP id tp1so120339070obc.2 for <v6ops@ietf.org>; Sat, 07 Nov 2015 22:21:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QK7RvY+sYZJ9uY5I8MgFyMZbU3ReI9OCl8FikK+mZUw=; b=MaM8xDqsbYCbbjYDTVTY7/A4NJK4qnVDvm/hhTuzw++ji0tU6ZKg2n5gIeIGRTlHC0 fAspKSUMw6eKaKlTvBNU5c7oEDLIqoylpTP1ixb6+C2gYYX9vuLJYtZ05xDsVd8N9M2b UHIk8ifIWoaKUnx3aTeaAOxO9ccnmeavXDBBoZk70+168dgT6MFq22Ty15K2iqrTRs6h 8WMWQMQR6yk+sFLfK/SlWa3WpDsMHURm9kzVZAPRlX0s19o7d/pCHYWW6D6beycb4+p/ CyElrRoK3pWcRDI9Gh+xPXez//WC3dl29YdbgkYSJn3LT/j3i7WIv1KV+AfefKeDrggF WBBg==
X-Received: by 10.182.181.65 with SMTP id du1mr12952269obc.71.1446963705227; Sat, 07 Nov 2015 22:21:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.202.84.197 with HTTP; Sat, 7 Nov 2015 22:21:05 -0800 (PST)
In-Reply-To: <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com>
References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <2134F8430051B64F815C691A62D9831832F391A7@XCH-BLV-504.nw.nos.boeing.com> <CAKD1Yr15C-uoxUw0kgWO-d=LmUK8qWGLS7vt+22W+k8xXtDY+g@mail.gmail.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com>
From: "Mukom Akong T." <mukom.tamon@gmail.com>
Date: Sun, 8 Nov 2015 10:21:05 +0400
Message-ID: <CAHDzDLBG8xZxUFsAuN-7WuruZcULF1QAS_ch=gD5rGQMZfskow@mail.gmail.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Content-Type: multipart/alternative; boundary=089e0158b49ea7317b0524017db3
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/095Q8RDZdjbWwqeEvoMCw-YDSCw>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Nov 2015 06:21:52 -0000

On 4 November 2015 at 03:30, Templin, Fred L <Fred.L.Templin@boeing.com>
wrote:

> Hi - let's lay this out fully so we can clearly understand the DAD
> implications.
>
> Let's say a node 'N' has a WAN interface (the one that connects to the
> provider
> network), a loopback interface, and a LAN interface (the one that connects
> to
> tethered hosts/networks).



If N is a node on a LAN, then it's 'WAN' interface is simply its Ethernet
or Wireless link and the it's 'provider' could be the subnet router. It's
'LAN' interfaces will be some virtual interfaces belonging to VMs for
example.



> 'N' sends a DHCPv6 PD Solicit over the WAN interface
> and receives a prefix delegation 'P'. 'N' can now assign prefix 'P' to
> either the
> loopback interface or the LAN interface, but MUST NOT assign 'P' to the WAN
> interface.



This is correct, since this WAN interface would have already gotten
legitimate non-link-local addresses by other means. The host would then be
requesting a PD only for other interfaces apart from the WAN interface.




> Now let's look at three cases:
>
> 1) 'N' assigns 'P' to the LAN interface and configures an address 'A' from
> 'P' that
>    it also assigns to the LAN interface. 'N' MUST do DAD on the LAN
> interface for
>    address 'A', but does not do DAD on the WAN interface because 'P' is not
>    assigned to that interface.
>


Isn't DAD done on addresses rather than prefixes? DAD will be done on A
because it is a full address (128 bits) that will be binded to the LAN
interface.

The language of 'assigning' a prefix to an interface is a bit confusing.
The current mechanisms for doing this today (creating a ND PIO for prefix P
or having P as some DHCPv6 scope) should not trigger DAD.



>
> 2) 'N' assigns 'A' and 'P' to the loopback interface. 'N' does not do DAD
>     on either the LAN or the WAN interface.
>


Correct, DAD is triggered per address per interface of N. Only one address
is being given to an interface (the loopback) and DAD will be done for
that. Again the use of 'assign' as applied to a prefix here is confusing .
One doesn't 'assign' a prefix to an interface and especially not loopback
interface AFAIK. There's no reason to do DAD on LAN/WAN interfaces because
no address is being assigned to them.



>
> 3) 'N' assigns 'P' to the loopback interface and assigns 'A' to the WAN
> interface.
>     Again, 'N' does not do DAD on the WAN interface because (again) 'P' is
> not
>     assigned to that interface.
>


I don't think this  is correct. DAD will be done for the WAN interface for
address A irrespective of whether P is 'assigned' to it (just as DAD is
performed for Link Local Addresses). If my understanding of your use of
'assigning' P is correct, then it could take the form of P being sent in a
PIO of a RA with A = 1. That act has no bearing on whether DAD is performed
until a host takes P, generates an IID and tries to assign it to an
interface.


>
> Now, stepping back, outside observers (e.g., neighbors on the WAN link)
> are completely oblivious to the way 'N' provisions 'P' and 'A' internally.


Correct.


> All an
> outside observer can tell is that 'N' emanates packets with source address
> 'A', and that 'P' is not on link. Therefore, there is no DAD required on
> the
> WAN interface.
>


If N is a host on a LAN (which requests a PD for VMS), then its WAN
interface is actually a LAN interface. Assuming it already provisioned an
address for that WAN interface, it doesn't need to provision A from the
delegated prefix. However I don't see any reason why it cannot provision an
address A from a sub-prefix (P') where P' is a sub prefix of P (e.g. it
gets a /60 P via PD, provisions a /64 P' and assigns address A out of P').
DAD must be done for that address A.




>
> Thanks - Fred
> fred.l.templin@boeing.com
>
> > -----Original Message-----
> > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L
> > Sent: Tuesday, November 03, 2015 2:37 PM
> > To: Brian E Carpenter; Lorenzo Colitti
> > Cc: v6ops@ietf.org
> > Subject: Re: [v6ops] DAD again [was:
> draft-ietf-v6ops-host-addr-availability discussion]
> >
> > Hi Brian,
> >
> > > -----Original Message-----
> > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> > > Sent: Tuesday, November 03, 2015 1:47 PM
> > > To: Templin, Fred L; Lorenzo Colitti
> > > Cc: v6ops@ietf.org
> > > Subject: DAD again [was: draft-ietf-v6ops-host-addr-availability
> discussion]
> > >
> > > Hello Fred,
> > >
> > > On 03/11/2015 20:10, Templin, Fred L wrote:
> > > > Hi Brian,
> > > >
> > > >> -----Original Message-----
> > > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> > > >> Sent: Monday, November 02, 2015 6:55 PM
> > > >> To: Templin, Fred L; Lorenzo Colitti
> > > >> Cc: v6ops@ietf.org
> > > >> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability
> discussion
> > > >>
> > > >> Hi Fred,
> > > >> On 03/11/2015 14:59, Templin, Fred L wrote:
> > > >>> Hi Brian,
> > > >>>
> > > >>>> -----Original Message-----
> > > >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> > > >>>> Sent: Monday, November 02, 2015 5:46 PM
> > > >>>> To: Templin, Fred L; Lorenzo Colitti
> > > >>>> Cc: v6ops@ietf.org
> > > >>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability
> discussion
> > > >>>>
> > > >>>> On 03/11/2015 14:31, Templin, Fred L wrote:
> > > >>>>> Bumping up one level – is it clear to everyone that it is OK to
> assign addresses
> > > >>>>> taken from a DHCPv6 delegated prefix to the interface over which
> the prefix
> > > >>>>> was received?
> > > >>>>
> > > >>>> If it was legitimately received, I can't see why it wouldn't be
> OK.
> > > >>>
> > > >>> OK. When the DHCPv6 server grants a prefix delegation to the
> client,
> > > >>> the server is asserting that that prefix is unique and is now the
> sole
> > > >>> property of the client. So, when you say legitimately received I
> > > >>> agree and that is actually a core requirement of DHCPv6 PD.
> > > >>> Otherwise, if the DHCPv6 server gave out duplicate prefixes, the
> > > >>> routing system would become hopelessly corrupted and address
> > > >>> duplication would be the least of our worries.
> > > >>>
> > > >>>>> And, that DAD is not required for those addresses?
> > > >>>>
> > > >>>> How is that safe? What is to stop a host running SLAAC once it
> > > >>>> sees that prefix in an RA, and hitting the same IID by chance?
> > > >>>> At least you need to specify that the A bit must not be set.
> > > >>>
> > > >>> I am talking about DAD on interface "A" being the interface over
> > > >>> which the client receives the prefix delegation. No other node on
> > > >>> interface "A" may use the delegated prefix, and no router on
> > > >>> interface "A" may advertise the prefix in an RA. The prefix is the
> > > >>> sole property of the client that received the PD, so the client is
> > > >>> free to assign addresses without needing DAD.
> > > >>
> > > >> That usage of "may" might confuse some people, so let's pretend
> > > >> you used a "MUST NOT" construct instead. I could still construct
> > > >> a host stack that would ignore the issue: its logic would be
> > > >> "I sent an RS and got no RA/PIO with A=1; but I see traffic from
> > > >> prefix 2bad:dead:beef::/64, so I'll do SLAAC and DAD in that
> prefix."
> > > >
> > > > The malicious (or otherwise broken) host 'A' could configure any
> number
> > > > of addresses it likes, but it would do so in a vacuum because ingress
> > > > filtering will prevent a packet with a source address from a prefix
> > > > belonging to host B from being accepted. So, node B has no reason
> > > > to fear address duplication by node A.
> > >
> > > I'm not sure how an ingress filter somewhere upstream would know that
> > > the packet came from the "wrong" host. But I don't think that's enough;
> > > a duplicate address on the LAN is already a problem in itself.
> > >
> > > > Also, what if node B in fact did do DAD and A heard it? What is to
> stop
> > > > A from configuring a duplicate address and trying to use it just to
> mess
> > > > up the legitimate operation of node B?
> > >
> > > Nothing. That, I think, is why the RFCs make DAD mandatory.
> > >
> > > >
> > > > What you are describing is a broken implementation that could only
> > > > be employed by a malicious host, and not something that honors
> > > > the standards.
> > >
> > > I don't think it's malicious; it's just trying to get IPv6 connectivity
> > > in the face of what it sees as a broken router that isn't responding
> > > to RS. But that isn't really my point - my point is that whatever we
> > > do, it's impossible to assert that a duplicate address will never
> arise.
> > >
> > > > Doing DAD is not going to guard against malicious
> > > > hosts.
> > >
> > > No, but it might allow you to detect the resulting anomaly.
> >
> >
> > Actually, the simpler answer to your question is that the node would
> > act as a host internally, but appear to be a router on the link from an
> > outside observer's perspective. And, routers do not do DAD for the
> > source addresses of packets that pass through them.
> >
> > Thanks - Fred
> > fred.l.templin@boeing.com
> >
> > >    Brian
> > >
> > > >
> > > > Thanks - Fred
> > > > fred.l.templin@beoing.com
> > > >
> > > >>>> Come to that, a manual address might collide.
> > > >>>
> > > >>> The client itself is the only node that is permitted to assign
> addresses
> > > >>> from the delegated prefix to an interface, so there is no risk of
> > > >>> collision unless the client itself is somehow corrupt.
> > > >>
> > > >> Or another client on the same LAN gets too clever.
> > > >>
> > > >>    Brian
> > > >>
> > > >>>
> > > >>> Thanks - Fred
> > > >>> fred.l.templin@boeing.com
> > > >>>
> > > >>>>     Brian
> > > >>>>
> > > >>>>>
> > > >>>>> Thanks - Fred
> > > >>>>>
> > > >>>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of
> Templin, Fred L
> > > >>>>> Sent: Monday, November 02, 2015 5:24 PM
> > > >>>>> To: Lorenzo Colitti
> > > >>>>> Cc: v6ops@ietf.org
> > > >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability
> discussion
> > > >>>>>
> > > >>>>> Hi Lorenzo,
> > > >>>>>
> > > >>>>> Responses below in “green”:
> > > >>>>>
> > > >>>>> From: Lorenzo Colitti [mailto:lorenzo@google.com]
> > > >>>>> Sent: Monday, November 02, 2015 5:04 PM
> > > >>>>> To: Templin, Fred L
> > > >>>>> Cc: Fred Baker (fred); v6ops@ietf.org<mailto:v6ops@ietf.org>
> > > >>>>> Subject: Re: [v6ops] draft-ietf-v6ops-host-addr-availability
> discussion
> > > >>>>>
> > > >>>>> On Tue, Nov 3, 2015 at 8:59 AM, Templin, Fred L <
> Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:
> > > >>>>> I have one text addition suggestion and one question. On P. 7,
> in Table 1,
> > > >>>>> suggest adding a new final row as follows:
> > > >>>>>
> > > >>>>>   requires DAD               Yes                  Yes
>        No                 N/A
> > > >>>>>
> > > >>>>> Meaning that multi-addresses configured by SLAAC or DHCPv6
> IA_NA/IA_TA
> > > >>>>> must use DAD to check for duplicates on the link they were
> obtained. In a
> > > >>>>> multi-addressing environment where millions of addresses are
> required,
> > > >>>>> this could amount to a substantial amount of DAD multicast
> traffic. On the
> > > >>>>> other hand, DAD is not needed for DHCPv6 PD because the network
> has
> > > >>>>> unambiguously delegated the prefix for the node's exclusive use.
> > > >>>>>
> > > >>>>> I don't think "Requires DAD: No" is correct. Even if the device
> gets a /64 prefix entirely for its own use, it still needs to do DAD
> > > with
> > > >>>> any other devices on that /64 (e.g., tethered devices, VMs, etc.).
> > > >>>>>
> > > >>>>> I'm not opposed to adding a line to the table, though I don't
> think it provides much value - if we put our mind to it, I'm sure
> > we
> > > >> could
> > > >>>> come up with lots of things we could add to the table that aren't
> there at the moment. My main concern is that if we add
> > > >> something to
> > > >>>> the table it needs to be correct.
> > > >>>>>
> > > >>>>> What I mean is “Requires DAD on the interface over which the
> prefix was received”,
> > > >>>>> but that was too long to fit in the table. Let’s call the
> interface “A”. If the node gets
> > > >>>>> SLAAC addresses or DHCP IA_NA/IA_TA addresses over interface
> “A”, then it needs
> > > >>>>> to do DAD on interface “A” for each such address. If the node
> gets a DHCPv6 PD
> > > >>>>> over interface “A”, however, it does not need to do DAD over
> interface “A” at all.
> > > >>>>>
> > > >>>>> If the node assigns the delegated prefix to interface “B”, then
> you are right that
> > > >>>>> that DAD will be required among all tethered devices, VMs, etc.
> on interface “B”.
> > > >>>>> But, there will still be no need for DAD on interface “A”. Does
> that clarify?
> > > >>>>>
> > > >>>>> I have a question also on table 1. Under ""Unlimited"
> endpoints", why does
> > > >>>>> it say "no" for DHCPv6 PD? I think it should say "yes" instead,
> since a prefix
> > > >>>>> obtained by DHCPv6 PD can be used to configure an unlimited
> number of
> > > >>>>> addresses on the link over which the prefix was received.
> > > >>>>>
> > > >>>>> The table is written from the perspective of the network
> assigning addresses to devices that connect to it. Therefore, it says
> > > "no"
> > > >>>> because if you use DHCPv6 PD you can't assign address space to an
> unlimited number of endpoints - you are limited to
> > however
> > > >> many
> > > >>>> /64s you have available.
> > > >>>>>
> > > >>>>> If you use IA_NA or SLAAC, any network with a /64 subnet has, at
> least in theory, an "unlimited" number of addresses to
> > assign
> > > to
> > > >>>> clients. Of course, that's only true in theory. In practice,
> there's going to be a limit due to scaling reasons.
> > > >>>>>
> > > >>>>> I don’t understand this. True that SLAAC and DHCPv6 IA_NA/IA_TA
> can be used
> > > >>>>> to assign an unlimited number of addresses to interface “A”.
> But, so can DHCPv6
> > > >>>>> PD. When the node receives the delegated prefix (e.g., a /64),
> it can assign as
> > > >>>>> many unique IPv6 addresses as it likes to interface “A”. And
> again, it need not
> > > >>>>> do DAD for any of them.
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> _______________________________________________
> > > >>>>> v6ops mailing list
> > > >>>>> v6ops@ietf.org
> > > >>>>> https://www.ietf.org/mailman/listinfo/v6ops
> > > >>>>>
> > > >>>
> > > >
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>



-- 

Mukom Akong T.

LinkedIn:Mukom <https://www.linkedin.com/in/mukom>  |  twitter:
@perfexcellent


------------------------------------------------------------------------------------------------------------------------------------------
“When you work, you are the FLUTE through whose lungs the whispering of the
hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------