RE: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]

[Dave Thaler <[e-mail]>]

See
http://tools.ietf.org/html/draft-ietf-ipngwg-site-prefixes-05

-Dave

> -----Original Message-----
> From: Mark Andrews [mailto:[e-mail]]
> Sent: Friday, March 16, 2012 5:13 PM
> To: Brian E Carpenter
> Cc: Arifumi Matsumoto; Bob Hinden; [e-mail]; Brian Haberman; Dave
> Thaler
> Subject: Re: ULA scope [draft-ietf-6man-rfc3484-revise-05.txt]
> 
> 
> In message <[e-mail]>, Brian E Carpenter writes:
> > On 2012-03-16 23:30, Arifumi Matsumoto wrote:
> > ...
> > > Rather, my question was about the design choice.
> > >
> > > Regarding the design of ULA and how to use the ULA, can we agree
> > > that ULA-to-ULA communication within the same /48 prefix is not
> > > always preferred over other communications using IPv4 or IPv6 global
> addresses ?
> >
> > I would expect it to be preferred as a result of longest match; I
> > would not expect it to be a special case in the default policy for
> > global scope addresses, if that is the question.
> >
> > >>> Second,
> > >>> when a user configures his policy table, the configured table is
> > >>> overwrit
> > ten by
> > >>> this implementation dependent policy injection behavior ?
> > >>> Can the user suppress this behavior of policy injection ?
> > >>> This issue should arise also when a policy distributing mechanism
> > >>> is read
> > y.
> > >> Good questions.  Do you have suggested answers to those questions?
> > >> I might throw out a strawman of:
> > >>
> > >> Any automatic rows added by the implementation as a result of
> > >> address acquisition MUST NOT override a row for the same prefix
> configured
> > >> via other means.   That is, rows can be added but never updated
> > >> automatically.   An implementation SHOULD provide a means for
> > >> an administrator to disable automatic row additions.
> > >
> > >
> > > My suggested answer for this was to use macros, which can be
> > > added/deleted by a user, and interpreted as the actual prefix
> > > attached to the hosts.
> >
> > That's an implementation method. I think Dave's proposed rule is
> > correct.
> >
> >     Brian
> 
> What I see missing is a way for a node to know what the site boundaries
> are with respect to address selection.   Adding a site prefix length
> to RA Prefix Information would provide a 99.99% solution to this.  If the Site
> Prefix field is non-zero it is valid.
> 
> e.g.
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |    Length     | Prefix Length |L|A| Reserved1 |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                         Valid Lifetime                        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                       Preferred Lifetime                      |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |  Site Prefix  |           Reserved2                           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +                            Prefix                             +
>       |                                                               |
>       +                                                               +
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]