Hi,
I'm not hearing much in response to the open issue:
Should we delete most of the text concerning stateful methods
of handling the flow label?
In fact I'm not hearing much at all. Should I ask the WG Chairs
to conclude that everybody is OK with these drafts? That would
save us some time i
On Sun, 6 Mar 2011 11:40:12 +0100 (CET)
Mikael Abrahamsson wrote:
> On Sun, 6 Mar 2011, Mark Smith wrote:
>
> > I don't think I said an on-link prefix was required. All I have ever
> > said is that, as per the RFC5942, if you want to have an on-link
> > prefix, you must announce it in a PIO (wit
On 3/5/11 5:28 PM, Karl Auer wrote:
> On Sat, 2011-03-05 at 09:49 -0500, Scott Schmit wrote:
>> I'm leaning toward the interpretation being "if you're in fe80::/10,
>> you're link local, but addresses outside fe80::/64 are reserved."
>
> Linux treats link local addresses as being in a /64:
>
> wl
On Sun, 6 Mar 2011, sth...@nethelp.no wrote:
*What netmask should the client use for the received address* in this
case?
When we tested this, it used /128 which is the only sane behaviour I can
see.
The only obvious alternatives I can think of are /64 and /128, since
the IA_NA address does
> I don't think I said an on-link prefix was required. All I have ever
> said is that, as per the RFC5942, if you want to have an on-link
> prefix, you must announce it in a PIO (without the A bit if you don't
> want it to be used for SLAAC). Steinar gave an example which could
> imply that wasn't
On Sun, 6 Mar 2011, Mark Smith wrote:
I don't think I said an on-link prefix was required. All I have ever
said is that, as per the RFC5942, if you want to have an on-link
prefix, you must announce it in a PIO (without the A bit if you don't
want it to be used for SLAAC).
You said:
I don't t
On Sun, 6 Mar 2011 10:47:06 +0100 (CET)
Mikael Abrahamsson wrote:
> On Sun, 6 Mar 2011, Mark Smith wrote:
>
> > The PIO isn't to make DHCPv6 work, it is to inform the end-host of what
> > destinations are onlink. Here is what RFC5942 says -
>
> Why does it need destinations on-link? It only nee
On Sun, 6 Mar 2011, Mark Smith wrote:
The PIO isn't to make DHCPv6 work, it is to inform the end-host of what
destinations are onlink. Here is what RFC5942 says -
Why does it need destinations on-link? It only needs to know it's IPv6
address and how to reach the router, nothing more. I don't
On Sun, 6 Mar 2011 09:54:42 +0100 (CET)
Mikael Abrahamsson wrote:
> On Sun, 6 Mar 2011, Mark Smith wrote:
>
> > I don't think that will always work. The PIO is needed to indicate to
> > end-nodes what the onlink prefix(es) are, as per RFC5942.
>
> Why do they need to know that?
>
> In our tes
On Sun, 06 Mar 2011 09:49:11 +0100 (CET)
sth...@nethelp.no wrote:
> > > > So in summary -
> > > >
> > > > RA with M and O bits set
> > > > PIO in RA with prefix(es) with L bit on and A bit off
> > > >
> > > > will force DHCPv6.
> > >
> > > Or, alternatively, RA with M and O bits set and no pref
On Sun, 6 Mar 2011, Mark Smith wrote:
I don't think that will always work. The PIO is needed to indicate to
end-nodes what the onlink prefix(es) are, as per RFC5942.
Why do they need to know that?
In our testing at least under Linux did just fine by knowing how to reach
the router and that i
> > > So in summary -
> > >
> > > RA with M and O bits set
> > > PIO in RA with prefix(es) with L bit on and A bit off
> > >
> > > will force DHCPv6.
> >
> > Or, alternatively, RA with M and O bits set and no prefix at all.
> >
>
> I don't think that will always work. The PIO is needed to indi
On Sun, 06 Mar 2011 09:02:18 +0100 (CET)
sth...@nethelp.no wrote:
> > So in summary -
> >
> > RA with M and O bits set
> > PIO in RA with prefix(es) with L bit on and A bit off
> >
> > will force DHCPv6.
>
> Or, alternatively, RA with M and O bits set and no prefix at all.
>
I don't think tha
> So in summary -
>
> RA with M and O bits set
> PIO in RA with prefix(es) with L bit on and A bit off
>
> will force DHCPv6.
Or, alternatively, RA with M and O bits set and no prefix at all.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
---
14 matches
Mail list logo