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

Hi Iljitsch,
thank you for your comments.

On 2004/10/22, at 21:41, Iljitsch van Beijnum wrote:

> On 15-okt-04, at 11:01, Arifumi Matsumoto wrote:
>
>> 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
>
> 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.)

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.


>> 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
>
> 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.  :-)

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.

--
Arifumi Matsumoto
     Ubiquitous Computing Project
     NTT Information Sharing Platform Laboratories
     E-mail: [email protected]