Subject: New I-D Submitted (Re: Newbie Question about addressing impacts)

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 15 Oct 2004 18:01:57 +0900

Hi, all.

Though I guess lots of people on this list almost forgot
about this topic, I submitted 3 new I-Ds about Source Address
Selection issue.

The first one is a brief overview of our proposed model.
In short, in our model, ISPs provide Source Address Selection
Policies as well as Prefix Delegation Info by DHCP.
The consumer edge router receives those policies (from
multiple ISPs) and re-distribute them to end nodes.
End nodes put them into policy table, which leads to
appropriate source address selection.

http://www.nttv6.net/~arifumi/draft-arifumi-multi6-sas-policy-dist 
-00.txt

The second and third draft are new option proposals
for Neighbor Discovery Router Advertisement Message
and DHCPv6. Though I think these drafts should be
posted to other WG, such as IPv6 and DHC, these drafts
have close relationship with site-multihoming, so I
posted here first.

http://www.nttv6.net/~arifumi/draft-arifumi-ipv6-nd-source-address- 
selection-opt-00.txt
http://www.nttv6.net/~arifumi/draft-hirotaka-dhc-source-address- 
selection-opt-00.txt

Questions and comments are welcome.

On 2004/08/13, at 20:22, marcelo bagnulo braun wrote:

> Hi Brian, Arifumi,
>
> I am not sure that the policy table falls under this particular  
> component, since as i see it, the policy table is more related with  
> locator selection when there are no failures and it is used as a mean  
> to express administrative prefferences.
> Anyway, as i understand it, Arifumi is considering mechanisms to  
> distribute RFC3484 policy table, so this is not really related to  
> locator selection, but rather with centralized policy management.
> IMHO this will be a requirement, especially as the sites grow bigger,  
> because manually configuring the policy table of each hosts doesn't  
> seems a reasonable approach when there is a considerable number of  
> hosts.
> Well, in any case, i can see basically two options to provide  
> automatic configuration of RFC3484 policy table:
> - router Advertisement
> - dhcp option
>
> the porblem with RA is that the full policy table has to fit in a  
> single RA message, since imho the distribution of the policy table  
> should be atomic (having only part of the policy table configure may  
> cause undesired behaviour), in addition, RA requires the configuration  
> of the policy table in at least one router per link, which may be  
> cumbersome
> the problem with dhcp is that you need a dhcp server, but it provides  
> most of the desired features AFAICS
>
> imho, a policy distribution mechanism will be needed at some moment.
> We have made a couple of implementations in linux of the two policy  
> table distribution mechanisms, one using dhcp and another one using  
> RA, to see how this work.
> If anyone is interested, we can discuss it.
>
> Regards, marcelo
>
> El 12/08/2004, a las 16:26, Brian E Carpenter escribió:
>
>> One of the components we have already identified (see the minutes
>> from San Diego) is
>>
>>  Locator selection after a failure has been detected / Choose new  
>> address pair
>>
>> RFC 3484 policy distribution might be a possible solution
>> for that component. We aren't chartered to do basic design in
>> this WG, but it would certainly be good to see proof-of-concept
>> for this (and every) component.
>>
>>      Brian
>>
>>
>> Arifumi Matsumoto wrote:
>>> Oops, I forgot to send CC to multi6.
>>> -- 
>>> Hi marcelo,
>>>> Well, even if you do a per host locator selection you can still  
>>>> manage policy in a centralized fashion, if we define proper  
>>>> mechanisms to perform policy distribution, for instance a dhcp  
>>>> option for distributing RFC3484 policy table or something similar.  
>>>> However, i don't know how you can enforce policy in a centralized  
>>>> manner when locator selection is performed by the end hosts.
>>> I believe that such a mechanism for policy distribution
>>> is really important. By making use of the existing RFC3484
>>> framework, IMHO we can develop much manageable multi-home
>>> environment in a simple and easy manner.
>>> Now I'm working on this mechanism to publish a new I-D.
>>> But I'm not sure such kind of topic is appropriate for
>>> this WG or not. I believe this part of the technology should
>>> be necessary for some of the proposals discussed here, though.
>>> -- 
>>> Arifumi Matsumoto
>>>     Ubiquitous Computing Project
>>>     NTT Information Sharing Platform Laboratories
>>>     E-mail: [email-masked]
>>
>
>
>
--
Arifumi Matsumoto
     Ubiquitous Computing Project
     NTT Information Sharing Platform Laboratories
     E-mail: [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 22 Oct 2004 14:41:53 +0200

> http://www.nttv6.net/~arifumi/draft-arifumi-multi6-sas-policy-dist 

Hm, I'm worried about the policy information becoming too extensive to  
fit comfortably in DHCP or RA packets. I guess it would be possible to  
broadcast basic policy information this way and then create a cache of  
more specific information on-demand, e.g. when ICMP messages come in.

(The advantage of using RA here is that when connectivity changes, a  
lot of hosts can be informed quickly about a new policy.)

> http://www.nttv6.net/~arifumi/draft-hirotaka-dhc-source-address- 

Why must the padding be ones? On many systems, newly allocated memory  
is filled with zeros, so this would be easier. And then there's  
tradition.  :-)

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 25 Oct 2004 15:47:34 +0900

Hi Iljitsch,
thank you for your comments.

> lot of hosts can be informed quickly about a new policy.)

As you mention it, each method seems to have both merits and demerits.

IMHO, one of the demerits of ICMP error method is:
When an error occurs, packets have to be re-sent by the end host and
the host has to change the src-ip of the packets. This can cause
unignorable impacts on upper layers(L4 and above). We might have to
modify upper layers more than a bit.

Our proposal just makes use of the existing RFC 3484 mechanism and  
doesn't
demand such modifications.

As for the packet size issue, we are thinking of some devices.
- We've adopted prefix space compression in RA. Almost all the prefixes  
in SAS Policy are expected to be less than 64-bit length, so it is  
wasteful to allocate 128-bit space for each prefix field.
- We are also thinking of cutting down SAS Policy option, for example,  
once a minute, once every two packets or only for router solicitation.
- In cooperation with DHCP, RA only specifies O flag and SAS Policy  
information is delivered by DHCP.

> is filled with zeros, so this would be easier. And then there's  

This may look a bit tricky.
This is because 8-bit zero field means "::/0" in our specification.
But this is not essential, and can be changed by introducing "number of
prefix" field or something like that.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 25 Oct 2004 11:00:44 +0200

On 25-okt-04, at 8:47, Arifumi Matsumoto wrote:

> - We've adopted prefix space compression in RA. Almost all the 
> prefixes in SAS Policy are expected to be less than 64-bit length, so 
> it is wasteful to allocate 128-bit space for each prefix field.

That's good, but what troubles me is that when you can have N policy 
expressions in a packet, what happens when there is a need for N+1 
policy expressions?

> prefix" field or something like that.

If you just say in the draft "padding and end marker" this should clear 
everything up nicely in the draft.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 25 Oct 2004 20:15:26 +0900

Hi Iljitsch,

On 2004/10/25, at 18:00, Iljitsch van Beijnum wrote:

>> - We are also thinking of cutting down SAS Policy option, for 
>> example, once a minute, once every two packets or only for router 
>> solicitation.

First of all, please note that one RA packet can contain
as much as 132 prefixes when all the SAS Policies are /64,
or 184 prefixes for /48.
In general use, it seems to be almost improbable to fill
this space with valid source address selection policies.

In such a case, IMHO, these measures can be taken:
- As I mentioned in the previous e-mail, it is an alternative
   to fall back to DHCP by using O flag in RA message.
   DHCP is a UDP protocol, so it can be fragmented as specified
   in RFC 3315.
- The other alternative is to prune some of SAS Policies to
   fit in one RA packet. There can exist end nodes with no
   DHCP capability. For those nodes, it is often better to
   have part of SAS Policy Info. than to have nothing.

So, it might be a reasonable approach to make both O flag
and pruned SAS Policy info. included in one RA packet.
At least, this should be configurable by router administrators.
As for pruning, some algorithms can be possible. Based on my
intuition, it seems to be better to prune policies with
shorter prefix length, as shorter prefix length policies
has less priority and can be overridden by longer ones
in RFC 3484 Policy Table

> If you just say in the draft "padding and end marker" this should 
> clear everything up nicely in the draft.

Thank you for your advice.
I'll use that wording in my update draft.