Subject: [Int-area] Multilink subnet issues and proxy/relay DAD

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 2 Nov 2006 16:09:06 -0800

The question of proxy/relay DAD for multilink networks that
comprise shared links has come up on the NETLMM and Autoconf
mailing lists. Proxy/relay DAD is a mechanism whereby NS(DAD)
messages are relayed to the link on which a node with a
colliding address resides, with the colliding node's NA(DAD)
being relayed back to the link on which the soliciting node
resides. (The Target Link Layer Address Option in the relayed
NA(DAD) must not be changed by the relays to ensure proper
SEND operation in this process.)

James Kempf has twice indicated that there have been prior
discussions on this subject between Jari Arkko and Dave
Thaler, and that they should be consulted for further
information (see below), but several attempts to contact
them have so far produced no results.

To ensure a fair and open dialogue at IETF67, I am requesting
that Jari, Dave, James and others with firsthand information
address the following questions on the lists prior to the
meetings:

  1. What are the issues wrt proxy/relay DAD that would
     interfere with its adoption as a standard mechanism?
  2. What harmful on-link assumptions could there be for
     IPv6 Prefix Information Options that advertise a
     shared prefix with 'L=0'?
  3. Does the RFC1812 "subnet forwarding model" still apply
     to IPv6, when there are no IPv6 documents that reference
     RFC1812 normatively?
  4. What other non-obvious issues relating to multilink
     subnets for shared links need to be observed for NETLMM,
     Autoconf and other contexts?

Fred Templin
[email-masked]     

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Wednesday, November 01, 2006 1:50 PM
To: Templin, Fred L; Behcet Sarikaya; Alexandru Petrescu
Cc: [email-masked]
Subject: Re: How does "per-MN prefix model" simplify things? (was:
RE:[netlmm]Re: PMIP follow-up questions)

>You mentioned a while back that there were some discussions
>involving IAB and/or IESG members that indicated there might
>be some barrier to acceptance of a proxy/relay DAD solution.
>Can you say anything more about that?

Primarily DaveT's multi-link subnet draft. I think it would be prudent
to 
discuss the issue with him before the WG makes a decision. Also, I think
we 
should check with Jari to find out what he thinks. It is necessary that
Jari 
agree with anything the WG comes up with if we are to get IESG approval.

            jak 

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Jari Arkko <[email-masked]>
Date: Sat, 04 Nov 2006 22:30:00 -0800

Hi Fred,
>      interfere with its adoption as a standard mechanism?
Almost anything can be made to work, but often
the question is what works best or with least
changes. In particular, we can make proxy DAD
work, probably even with SEND. But I would
still prefer an approach that does not require
that. Also, if you need proxy DAD, does that
mean that link local multicast does not work
on the link as expected?
>      shared prefix with 'L=0'?
None that I know of.
>      Autoconf and other contexts?
I am not sure I have an answer. But let me ask you a
question about something which has been unclear
to me during the NETLMM discussion. What is the
real-world functionality that you would like to have?
Media where this is needed? Employing just one
prefix per a number of hosts? Special requirements
on what the scope of link local multicast should be?

Also, my understanding of the NETLMM decision
is that the working group wants to limit initial
design to per-host prefix model, but that this
could be extended in the future.

As for AUTOCONF, there are no decisions yet,
but my main requirement for them has been
that they must define their architecture, including
addressing and how links are seen from IP. And
avoid issues from Dave's draft if possible. The
architecture needs to be concrete enough so
that we can determine what protocol work is
needed for, e.g., prefix allocation, prefix/address
uniqueness checking, and gateway selection.

--Jari

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 6 Nov 2006 14:55:01 -0800

> mean that link local multicast does not work

The question is coming from the context of what to do
about two nodes connected to different links that configure
colliding addresses and then move onto the same link at
some later point in time. It seems that a pre-service DAD
procedure like proxy/relay DAD would be preferrable to an
in-service DAD, e.g., (re)marking addresses as tentative
and (re)running DAD on link change. 

>>      shared prefix with 'L=0'?

OK. If a node receives a PIO with 'L=0' and then configures
a /128 on an interface, could applications get confused and
assume that all destinations covered by the /64 that also
covers the /128 are on-link? Is this something that should
be added to an "on-link assumption considered harmful"
document? (The latest version of the 'multilink-subnet'
draft also says something about this.)
 
> on what the scope of link local multicast should be?

Aside from the question of shared prefixes for the moment,
even in just the link-local case the concern is for nodes
that can move within a region between shared media links
on which there may be neighbors other than just the
provider's router.

Proxy/relay-DAD is a pre-service DAD procedure for ensuring
that no two nodes in the region will configure the same LL
address prior to operation. Another possible method which
has been suggested by James and others is to somehow enforce
virtual point-to-point links as overlays on the shared media
such that the (mobile) nodes would only ever see their
provider's router on the link and no other neighbors. Such
an arrangement might not be appropriate for all media types
and/or deployments.

> could be extended in the future.

Well, the relay/proxy-DAD is also about link-locals;
not just non-link-locals configured from a shared
prefix. So, this is somewhat independent from the
per-host prefix question.

> uniqueness checking, and gateway selection.

Thanks for this and for the other perspectives,

Fred

--Jari

---

From: Julien Laganier <[email-masked]>
Date: Mon, 6 Nov 2006 15:58:34 -0800

Fred,

My follow-up inlined below,

On Monday 06 November 2006 14:55, Templin, Fred L 
wrote:
> >>   1. What are the issues wrt proxy/relay DAD that
> >> would interfere with its adoption as a standard
> >> mechanism?
> >
> The question is coming from the context of what to
> do about two nodes connected to different links that
> configure colliding addresses and then move onto the
> same link at some later point in time. It seems that
> a pre-service DAD procedure like proxy/relay DAD
> would be preferrable to an in-service DAD, e.g.,
> (re)marking addresses as tentative and (re)running
> DAD on link change.

Especially since this the default DNA behavior is to 
not redo DAD when DNA concludes that the link did not 
change -- because in the NetLMM case the landmark 
prefix won't change even though the link indeed 
changed.

Regarding the implications on link-local multicast, 
there's none since there's no change in the 
communication service model: Normal address resolution 
isn't impacted by proxy DAD, only NS and NA part of 
DAD would be proxied when a collision is detected by 
the NetLMM fabric, otherwise they won't.

> [...] 
>
> >>   3. Does the RFC1812 "subnet forwarding model"
> >> still apply to IPv6, when there are no IPv6
> >> documents that reference RFC1812 normatively?
> >>   4. What other non-obvious issues relating to
> >> multilink subnets for shared links need to be
> >> observed for NETLMM, Autoconf and other contexts?
> >
> > I am not sure I have an answer. But let me ask you
> > a question about something which has been unclear
> > real-world functionality that you would like to
> > have? Media where this is needed? Employing just
> > one prefix per a number of hosts? Special
> > requirements on what the scope of link local
> > multicast should be?
>
> Aside from the question of shared prefixes for the
> moment, even in just the link-local case the concern
> is for nodes that can move within a region between
> shared media links on which there may be neighbors
> other than just the provider's router.

I think the concern apply even when links are 
point-to-point and the only neighbor to a MN is the 
provider's router.

If a MN happens to move to a link where the router has 
a colliding link-local address, and the MN doesn't 
re-run DAD (as per default DNA behavior) then a 
collision will occur and won't be detected.

That's orthogonal to the link type, be it 
point-to-point or shared, I think.

> Proxy/relay-DAD is a pre-service DAD procedure for
> ensuring that no two nodes in the region will
> configure the same LL address prior to operation.
> Another possible method which has been suggested by
> James and others is to somehow enforce virtual
> point-to-point links as overlays on the shared media
> such that the (mobile) nodes would only ever see
> their provider's router on the link and no other
> neighbors. 

See my comment above.

> Such an arrangement might not be appropriate for all
> media types and/or deployments. 
>

Agree.

> [...]

Best,

--julien

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 6 Nov 2006 16:51:06 -0800

Hi Julien,

This all sounds good, but in terms of a node moving between
routers on p2p links I have seen some proposals that all
routers would configure the same LL address thereby avoiding
collisions after an initial DAD test with the first router.
(I guess that wouldn't be appropriate for shared links, since
there couldn't be multiple routers on the link with the same
LL address?)

Is there a problem with assigning the same LL address to
different routers whereby that shouldn't be done and we need
proxy/relay-DAD instead?

Fred

-----Original Message-----
From: Julien Laganier [mailto:[email-masked]] 
Sent: Monday, November 06, 2006 3:59 PM
To: [email-masked]
Cc: Templin, Fred L; Jari Arkko; [email-masked]; Dave Thaler;
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [netlmm] RE: Multilink subnet issues and proxy/relay DAD

Fred,

See my comment above.

Agree.

Best,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 6 Nov 2006 17:06:23 -0800

Hi Fred,

On Monday 06 November 2006 16:51, Templin, Fred L 
wrote:
>
> This all sounds good, but in terms of a node moving
> between routers on p2p links I have seen some
> proposals that all routers would configure the same
> LL address thereby avoiding collisions after an
> initial DAD test with the first router. (I guess
> that wouldn't be appropriate for shared links, since
> there couldn't be multiple routers on the link with
> the same LL address?)

AFAICS, mandating that on every link of the domain the 
same set of LL addresses is configured on the set of 
on-link routers would avoid problem when multiple 
routers are on-link.

> Is there a problem with assigning the same LL
> address to different routers whereby that shouldn't
> be done and we need proxy/relay-DAD instead?

There is a problem with the current SEND because that 
would require to share the same public key amongst 
those routers, and hence sharing the same private key 
as well. That wouldn't be good from a security point 
of view.

A solution exists if SEND is updated to support CGAs 
derived from multiple keys, or even ring signatures 
[1] in which multiple keys could be used to generate a 
CGA, each key being used by one router only.

--julien

draft-kempf-mobopts-ringsig-ndproxy
<http://www.watersprings.org/pub/id/draft-kempf-mobopts-ringsig-ndproxy-02.txt>

> From: Julien Laganier
> [mailto:[email-masked]] Sent: Monday,
> November 06, 2006 3:59 PM
> To: [email-masked]
> Cc: Templin, Fred L; Jari Arkko; [email-masked];
> Dave Thaler; [email-masked]; [email-masked];
> [email-masked] Subject: Re: [netlmm] RE: Multilink
> subnet issues and proxy/relay DAD
>
> Fred,
>
> > >>   1. What are the issues wrt proxy/relay DAD
> > >> that would interfere with its adoption as a
> > >> standard mechanism?
> > >
> > do about two nodes connected to different links
> > that configure colliding addresses and then move
> > onto the same link at some later point in time. It
> > seems that a pre-service DAD procedure like
> > proxy/relay DAD would be preferrable to an
> > in-service DAD, e.g., (re)marking addresses as
> > tentative and (re)running DAD on link change.
>
> not redo DAD when DNA concludes that the link did
> not change -- because in the NetLMM case the
> landmark prefix won't change even though the link
> indeed changed.
>
> communication service model: Normal address
> resolution isn't impacted by proxy DAD, only NS and
> NA part of DAD would be proxied when a collision is
> detected by the NetLMM fabric, otherwise they won't.
>
> > [...]
> >
> > > I am not sure I have an answer. But let me ask
> > > you a question about something which has been
> > > unclear to me during the NETLMM discussion. What
> > > is the real-world functionality that you would
> > > like to have? Media where this is needed?
> > > Employing just one prefix per a number of hosts?
> > > Special requirements on what the scope of link
> > > local multicast should be?
> >
> > moment, even in just the link-local case the
> > concern is for nodes that can move within a region
> > between shared media links on which there may be
> > neighbors other than just the provider's router.
>
> If a MN happens to move to a link where the router
> has a colliding link-local address, and the MN
> doesn't re-run DAD (as per default DNA behavior)
> then a collision will occur and won't be detected.
>
> > Another possible method which has been suggested
> > by James and others is to somehow enforce virtual
> > point-to-point links as overlays on the shared
> > media such that the (mobile) nodes would only ever
> > see their provider's router on the link and no
> > other neighbors.
>
> See my comment above.
>
> > Such an arrangement might not be appropriate for
> > all media types and/or deployments.
> >
> > Well, the relay/proxy-DAD is also about
> > link-locals; not just non-link-locals configured
> > from a shared prefix. So, this is somewhat
> > independent from the per-host prefix question.
>
> Agree.
>
> > [...]
>
> Best,
>
> --julien

---

From: "James Kempf" <[email-masked]>
Date: Mon, 6 Nov 2006 18:08:06 -0800

Julien,

Yes, multikey CGAs would solve the problem. Each router has its own private 
key used to sign, the CGA is generated using multiple keys, and the 
signature is validated using multiple public keys.

But that would require a modification to SEND.

            jak

----- Original Message ----- 
From: "Julien Laganier" <[email-masked]>
To: "Templin, Fred L" <[email-masked]>
Cc: <[email-masked]>; "Dave Thaler" <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, November 06, 2006 5:06 PM
Subject: Re: [netlmm] RE: Multilink subnet issues and proxy/relay DAD

> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm