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
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 that will always
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 indicate to
end-nodes what
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
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 prefix at all.
I don't
On Sun, 6 Mar 2011 09:54:42 +0100 (CET)
Mikael Abrahamsson swm...@swm.pp.se 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
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 10:47:06 +0100 (CET)
Mikael Abrahamsson swm...@swm.pp.se 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
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
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 the
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
On Sun, 6 Mar 2011 11:40:12 +0100 (CET)
Mikael Abrahamsson swm...@swm.pp.se 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
And, keep in mind, one can use abitrary prefixes by turning off
stateless address autoconfiguration and using DHCPv6.
we wish. there is still the exciting mess of ra.
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
On Sun, 06 Mar 2011 13:20:40 +0900
Randy Bush ra...@psg.com wrote:
And, keep in mind, one can use abitrary prefixes by turning off
stateless address autoconfiguration and using DHCPv6.
we wish. there is still the exciting mess of ra.
Your wishes are already true. You switch off the
No. EUI-64 requires 64 bit host id's. 48 bits is from the MAC. How
would you plan to squeeze blood out of the proverbial turnip?
perhaps going back and reading thomas's message would help dispel this
odd religion.
http://www.ietf.org/mail-archive/web/ipv6/current/msg13461.html
randy
I stand corrected.
That said, updating the specs to allow a site to use stateless address
autoconfiguration with prefix lengths other than /64 would almost
certainly require updating both specs.
The stateless autoconfig spec would need to be tweaked to convert the
IID produced by the specific
This could probably all be defined in a way that is an optional
extension to stateless address autoconfig. So it wouldn't necessarily
cause confusion or delay getting IPv6 deployed.
I agree.
Yu Hua bing
IETF IPv6 working
On Mar 3, 2011, at 12:58 AM, TJ wrote:
On Wed, Mar 2, 2011 at 17:32, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
snip
I'd rather get IPv6 deployed in a uniform way first.
I'd take that sentence a step or two further:
I'd rather get IPv6 deployed in a uniform way.
or even
To: Brian E Carpenter
Cc: Scott W Brim ; Thomas Narten ; ipv6 ; huabing yu
Subject: Re: draft-yhb-6man-slaac-improvement-00
On Wed, Mar 2, 2011 at 17:32, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
snip
I'd rather get IPv6 deployed in a uniform way first.
I'd take that sentence
_
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Yu
Hua bing
Sent: Thursday, March 03, 2011 9:50 AM
To: trej...@gmail.com; Brian E Carpenter
Cc: Thomas Narten; ipv6; Scott W Brim
Subject: [BULK] Re: draft-yhb-6man-slaac-improvement-00
Importance: Low
I think
To: Yu Hua bing ; trej...@gmail.com ; Brian E Carpenter
Cc: Thomas Narten ; ipv6 ; Scott W Brim
Subject: RE: [BULK] Re: draft-yhb-6man-slaac-improvement-00
I think that SLAAC should be deployed in the sites which use the prefixes
longer than 64.
Don't put a limit on the prefix length.
DHCPv6 can
Cc: Thomas Narten ; ipv6 ; Scott W Brim
Subject: RE: [BULK] Re: draft-yhb-6man-slaac-improvement-00
I think that SLAAC should be deployed in the sites which use the prefixes
longer than 64.
Don't put a limit on the prefix length.
DHCPv6 can be deployed in the sites which use
Cc: Thomas Narten ; ipv6 ; Scott W Brim
Subject: RE: [BULK] Re: draft-yhb-6man-slaac-improvement-00
I think that SLAAC should be deployed in the sites which use the prefixes
longer than 64.
Don't put a limit on the prefix length.
DHCPv6 can be deployed in the sites which use
Smith
Cc: Thomas Narten; ipv6; Scott W Brim; Duncan,Richard J. (Jeremy)
CONTRACTOR; Yu Hua bing
Subject: Re: [BULK] Re: draft-yhb-6man-slaac-improvement-00
Yes, and in fact draft-ietf-v6ops-3177bis-end-sites deals
with this and will be an RFC soon:
https://datatracker.ietf.org/doc/search/?name
, 2011 1:59 PM
To: Brian E Carpenter
Cc: ipv6
Subject: RE: [BULK] Re: draft-yhb-6man-slaac-improvement-00
I guess I'm missing what the solution is.
As 3177-bis says, the IETF has no control over how service providers hand
out IPv6 address space. From what I've been reading in the past few years
Narten ; ipv6 ; Scott W Brim
Subject: RE: [BULK] Re: draft-yhb-6man-slaac-improvement-00
I think that SLAAC should be deployed in the sites which use the
prefixes longer than 64.
Don't put a limit on the prefix length.
DHCPv6 can be deployed in the sites which use the prefixes longer
than 64
On Thu, Mar 3, 2011 at 16:59, Manfredi, Albert E
albert.e.manfr...@boeing.com wrote:
I guess I'm missing what the solution is.
The solution is for providers to not give out just /64s :).
As 3177-bis says, the IETF has no control over how service providers hand
out IPv6 address space. From
On Mar 3, 2011, at 2:10 PM, TJ wrote:
As 3177-bis says, the IETF has no control over how service providers hand out
IPv6 address space. From what I've been reading in the past few years, it
looks like at least some providers are planning to give /64s to customers.
Really? None of the
On 03/03/2011 06:50, Yu Hua bing wrote:
DHCPv6 can be deployed in the sites which use the prefixes longer than
64.Why can't SLAAC?
Because SLAAC was not designed as a general-purpose mechanism, and
should not be modified (further) to be so.
Doug
--
Nothin' ever doesn't change,
On Mar 3, 2011, at 2:10 PM, TJ wrote:
Really? None of the ISPs I have spoken with, and certainly none of
the ones I have worked with, are following a /64 per client plan. I
have discussed /48s vs /56s vs /60s ... but never a /64.
James Woodyatt wrote:
Here is a Reddit commenter from
In message b0147c3dd45e42478038fc347ccb65fe02a7643...@xch-mw-08v.mw.nos.boeing
.com, Manfredi, Albert E writes:
I guess I'm missing what the solution is.
As 3177-bis says, the IETF has no control over how service providers hand out
IPv6 address space. From what I've been reading in the past
Sent: Wednesday, March 02, 2011 9:50 AM
To: huabing yu
Subject: Re: draft-yhb-6man-slaac-improvement-00
Let me play devil's advocate:
What problem are you really trying to solve? Have you balanced the perceived
value of the fix with the impact of implementing such (especially vendor
Hi
We have no right to require that the sites MUST use 64-bit prefixes.
Actually, we do have that right. Since the IETF sets Internet standards,
we can write exactly what we want to. IETF standards are voluntary,
so sites have the right to ignore them too. However, if they do that,
they will
[RFC4862] requires that subnets operating stateless address
autoconfiguration use 64 bit prefixes,
Actually, not true! Stateless address autoconfiguration supports
different prefix lengths just fine. That was a deliberate design
decision, even after we switched to 64-bit Interface IDs. E.g
I stand corrected.
BTW there is also the issue of interaction with ILNP, which
has been recommended to the IETF by the RRG chairs.
Brian
On 2011-03-03 10:25, Thomas Narten wrote:
[RFC4862] requires that subnets operating stateless address
autoconfiguration use 64 bit prefixes,
Actually,
On Wed, Mar 2, 2011 at 17:10, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
BTW there is also the issue of interaction with ILNP, which
has been recommended to the IETF by the RRG chairs.
ILNP is barely experimental, its probability of being widely deployed is
totally unknown, and in
On 2011-03-03 11:23, Scott W Brim wrote:
On Wed, Mar 2, 2011 at 17:10, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
BTW there is also the issue of interaction with ILNP, which
has been recommended to the IETF by the RRG chairs.
ILNP is barely experimental, its probability of
On Wed, Mar 2, 2011 at 17:32, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
snip
I'd rather get IPv6 deployed in a uniform way first.
I'd take that sentence a step or two further:
I'd rather get IPv6 deployed in a uniform way.
or even simpler:
I'd rather get IPv6 deployed.
To be
I'd rather get IPv6 deployed in a uniform way first.
try cidr
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Hi.
This is my draft, the link is
http://datatracker.ietf.org/doc/draft-yhb-6man-slaac-improvement/?include_text=1
Please give some advice.Thank you.
Abstract
IPv6 stateless address autoconfiguration described by RFC4862 only supports
64-bit prefixes. This approach can't be deployed in the
40 matches
Mail list logo
