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

[Arifumi Matsumoto <a@arifumi.net>]

Hi Iljitsch,

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

> On 25-okt-04, at 8:47, Arifumi Matsumoto wrote:
>
> > 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.
>
> 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?

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

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

--
Arifumi Matsumoto
    Ubiquitous Computing Project
    NTT Information Sharing Platform Laboratories
    E-mail: arifumi@nttv6.net