Subject: Re: Issue 13: Omission of prefix options - resolution

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 04 Nov 2003 19:16:34 +0900

>Suggested resolution:
>
>- Introduce a new code (1) in the router solicitation
>and advertisement. When a host sends an RS with code = 1
>it requests that the RA include all prefixses valid on
>that link. Similarly, when a router sends an RA with code=1
>it means that the RA includes all prefixes valid on that
>link. This way, a MN can confirm its mobility.

	we cannot always correlate RS and RA (router can listen to RS, then
	issue RA on the next periodic advertisement).  also RS does not solicit
	unicast RA.  the above solution does not work.

itojun

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Nov 2003 12:24:19 +0200 (EET)

> link. This way, a MN can confirm its mobility.

I don't think this is necessary.  There is plenty of space in RA's to
include the prefixes.  So, we're basically talking about the case where
the network administrator has intentionally not advertised all the
prefixes (in which case we need to educate them, but not necessarily in
this document).

Instead, I'd propose to explain that omitting prefixes could have adverse
effects. (And also, without going into it in too much depth, maybe
describe *which* adverse effects, but that's a potential can of worms.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Markku Savela <[email-masked]>
Date: Tue, 4 Nov 2003 12:25:18 +0200

> Comments?

How does this work with multiple routers on the link in various
combinations? Like

- Routers may advertise different sets of prefixes, each their own. I
  don't there is any requirement for routers on link to advertise the
  same set of prefixes?

- I was just experimenting with
  draft-ietf-ipngwg-router-selection-00.txt and have a "router" that
  sends RA with lifetime=0 (not a default router), 1 preferred route
  option, no prefixes.

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 4 Nov 2003 20:29:33 +0900

> describe *which* adverse effects, but that's a potential can of worms.)

Even though an RA contains all the prefixes, there is no indication that it does. 

After link change, if an RA without the prefix of its current CoA arrives, mobile 
node can't be sure that its CoA is no longer valid. Hence still uncertainty remains 
for a mobile node.  LR¿¬(®H§‚
èº™šŠX§‚X¬¶*oê'~ŠàÙ¢ž+-«b½ä^ªç¬¶Èm¶›?ÿ0Ö'~Šàþf¢–f§þX¬¶)ß£ø©¿

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Nov 2003 13:39:56 +0200 (EET)

On Tue, 4 Nov 2003, JinHyeock Choi wrote:
> After link change, if an RA without the prefix of its current CoA
> arrives, mobile node can't be sure that its CoA is no longer valid.
> Hence still uncertainty remains for a mobile node.

Hence, we need to either make it clearer that the prefixes are not
omitted, or make up better movement detection mechanisms.

Do you have any specific reasons for this?

There is really no reason to omit those prefixes that I could see.  
Rather than adding new code to verify this, shouldn't we just warn about
this situation and be done with it?  Or even state that prefixes SHOULD
NOT (or MUST NOT) be omitted unless including them would cause a too big
packet (over MTU) to be sent?

That is, we seem to have different high-level views to this issue.  I
don't see that we need to fix this theoretical(?) problem, rather try to
ensure that it won't happen.

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 4 Nov 2003 20:59:08 +0900

Markku Savela wrote
>   don't there is any requirement for routers on link to advertise the

This is a problem. Two routers on a link advertising different set of 
prefixes makes movement detection complicated. 

In this case, we may let each router be implemented with the host-specific 
part of Prefix Discovery. Hence it knows that the prefixes advertised by 
other routers and advertises them in its own RAs. This may be a possible 
solution but needs further elaboration.  

But currently the best solution seems to avoid such a scenario. :-)

By the way, while working on MD, we came across a similar issue of 
'on-link prefix on a wireless link' as belows.  

Assume there are two Routers, Router1 and Router 2 on a link like 
a figure. They share one Access Point between them. 

                         |                |
                       __|____          __|____
                      |       |        |      |
                      |Router |        |Router|
                      |___1__ |        |___2__|                 
                          |                |
                      A:: |                |  B::  
                        __|________________|_____       
                                    |
                                  __|____                      
                                  |Access|                    
                                  | Point|                       
                                  |___ __|  

Two routers advertise two different prefixes on their wireless interfaces. 
Router1 advertises the prefix A:: and Router2 advertises the the prefix B::. 

And they inject the related routes to Internet. Router1 injects route for A:: 
and Router2 injects route for B::.  

But assume Router1 is implemented with the host-specific part of Prefix 
Discovery. Hence it knows that the prefix B:: is assigned to the link by 
hearing RAs from Router2. 

Then what is the Router1's on-link prefixes on the wireless link? 
Is it {Prefix A::} or {Prefix A:: , Prefix B::}? 

We looked through the RFC 2461 but couldn't find much about 
routers implementing the Prefix Discovery to discover the other 
on-link prefixes. 

Best regards

JinHyeock.  

 DÅ ûúÂŠäŠx ®‹©™¨¥Šx%ŠËb¦þ¢z×è®š)â²ÚÚ¶+ÞEê®zËl†Ûi³ÿðÃ
bz×è®æj)fjåŠËbú?Š›ú

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 4 Nov 2003 21:25:01 +0900

Pekka Savola wrote
> omitted, or make up better movement detection mechanisms.

I think we agreed that it's necessary to make it clearer that the 
prefixes are not omitted. 

But it seems that I propose to indicate it explicitly by using code =1 
and you advocate to do it implicitly by mandating (is it too strong word?)
every RA contains all the prefixes. 

> packet (over MTU) to be sent?

For me, either way is O.K, whether explicit or implicit, if only it makes non
-omission clear. We'd better compare which way is more efficient, banning 
omission or adopting a new code. 

But here is the concern I have on implicit way. In wireless link, bandwidth
is a precious commodity. Mobile IPv6 reduces the lower bound of the Router 
Advertisement Intervals. Greg Daley calculated that the bandwidth consumption 
by multicast  beacons is 14 kbps when RAs only include one Prefix Information 
option. So in wireless environment, it may take too much bandwidth to advertise 
all the prefixes in all the RAs.  

Best regards 

JinHyeock

1H>þ°¢¹"ž+¢êfj)bž	b²Ø©¿¨žµú+€fŠx¬¶¶Š÷‘z«ž²Û!¶Úlÿü0ÃXžµú+ƒùšŠYšŸùb²Ø§~â¦þ

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 4 Nov 2003 13:20:32 +0100 (CET)

> packet (over MTU) to be sent?

Part of the consideration is the folks want to use RAs as frequent
beacons for attachment detection. Making such beacons to carry potentially
lots of prefixes, especially on bandwidth constrained (wireless) links,
might be self-defeating.

Thus recommending that all prefixes be sent every 10 milliseconds (or whatever
the min number is in the MIPv6 spec) might not be the best approach.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Nov 2003 14:50:09 +0200 (EET)

On Tue, 4 Nov 2003, Erik Nordmark wrote:
> beacons for attachment detection. Making such beacons to carry
> potentially lots of prefixes, especially on bandwidth constrained
> (wireless) links, might be self-defeating.
> 
> Thus recommending that all prefixes be sent every 10 milliseconds (or
> whatever the min number is in the MIPv6 spec) might not be the best
> approach.

Uhh, this seems like a total abuse of the RA mechanism :-).  The point of 
it to be able to carry the prefixes needed for autoconfiguration.  

If it's supposed to be used for a beacon mechanism, I'd suggest
considering whether one could find a method that does not send prefixes at 
ALL (or, just send the prefix of the router with prefixlen=128 if you 
really insist). 

This would enable you to retain the model where RA's would in fact be
complete when they included prefix information options that the nodes
would use.

---

From: Greg Daley <[email-masked]>
Date: Wed, 05 Nov 2003 13:14:03 +1100

Hi Pekka,

> it to be able to carry the prefixes needed for autoconfiguration.  

The final paragraph of Section 6.2.3 of rfc-2461
says that a router may want to omit options, but can't
do so for a solicited RA.  So the abuse isn't against
the carrying of all prefixes.

The abuse of the RA mechanism is certainly there though
(as abuse of wireless bandwidth).
Everyone at the mobileIP session at IETF55 knew that
it was a limited solution for some environments.

> complete when they included prefix information options that the nodes

There is a solution such as this which can omits all options
in unsolicited RA, and still allows us to identify that we're
on the same link or have moved.  This is equivalent to Complete
PIO information in RAs, but doesn't necessarily have the
prefixes present in unsolicited RAs.

It's called Link Identifiers.  Instead of (or as well as) sending
PIOs, a link identifier option is sent by all routers
on the same link.

This was described in Erik's MIPv6 hindsight document, but
recent work by Monash and Samsung has aimed at making this
LinkID Option small, and automatically configured.

It's available at:

http://www.ietf.org/internet-drafts/draft-pentland-mobileip-linkid-00.txt

This solution works if all routers on the link send LinkIDs,
or if not all routers do, but transmit overlapping prefixes.

The completeness bit would work even if no other routers
on the link support it though.

Of course, since section 6.2.3 recommends that
routers advertise all options in solicited RAs,
maybe the completeness bit could only be set in
solicited RAs, if LinkID was present.

There are some other things regarding RA contents
(there's no solicitation indication) which would
be nice, but I guess that's not what we're talking
about here.

So we have at least two solutions which provide
unambiguous prefix indications:

LinkID + Solicited RA (lower overhead)
Completeness Bit      (simpler)

Whether these are aimed at RFC-2461bis or receive
attention in IPv6 or DNA is another matter.

Greg