[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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: arifumi@nttv6.net