Thanks for this info. Clarification question:
I know I'm responding to an old message here, but in case anyone
finds this by searching the archive, I'd like to point out that
Apple supports DHCPv6 in current AirPort, Time Capsule, Apple TV,
iPhone, iPod Touch and iPad products. (As a policy
On Oct 20, 2010, at 05:25, Thomas Narten wrote:
Thanks for this info. Clarification question:
[I wrote:]
[...] I'd like to point out that Apple supports DHCPv6 in current AirPort,
Time Capsule, Apple TV, iPhone, iPod Touch and iPad products. [...]
Does this include DHCPv6 support for
James,
Thanks for the information. I also assume it will support IA_PD. If the
AirPort and Time Capsule receive a PD shorter than /64, what is the
behavior?
Yiu
On 10/20/10 12:08 PM, james woodyatt j...@apple.com wrote:
On Oct 20, 2010, at 05:25, Thomas Narten wrote:
Thanks for this info.
On Sep 22, 2010, at 02:24, Mikael Abrahamsson wrote:
On Wed, 22 Sep 2010, Rémi Després wrote:
Of course, if MS and Apple announce an upgrade of all their IPv6 stacks, to
the effect that they use DHCPv6 requests to obtain what they no longer get
in RAs, that would mitigate the need for
Mikael Abrahamsson swm...@swm.pp.se writes:
I deployed one-vlan-per-customer-subvlan with a shared /27 supernet on
Extreme Networks equipment in ~2002, the same thing can be done on
Cisco as well (ip address unnumbered lo10 and static routes for each
/32 to a specific vlan interface).
Thank
Le 22 sept. 2010 à 03:06, Christian Huitema a écrit :
no one is arguing nd/ra be removed entirely, as subnet anycast should be.
the argument is that there are environments where it is not needed and
dhcp should be able to be used in its place.
That's reasonable. There are cases where
On Wed, 22 Sep 2010, Rémi Després wrote:
Of course, if MS and Apple announce an upgrade of all their IPv6 stacks,
to the effect that they use DHCPv6 requests to obtain what they no
longer get in RAs, that would mitigate the need for backward
compatibility. But is this realistic?
As far as I
Le 22 sept. 2010 à 11:24, Mikael Abrahamsson a écrit :
On Wed, 22 Sep 2010, Rémi Després wrote:
Of course, if MS and Apple announce an upgrade of all their IPv6 stacks, to
the effect that they use DHCPv6 requests to obtain what they no longer get
in RAs, that would mitigate the need for
On Wed, 22 Sep 2010, Rémi Després wrote:
As far as I know Apple doesn't support DHCPv6 at all.
You are misinformed, and that's IMHO important information: I have been
using IPv6 from my MacBook SINCE DECEMBER 2007.
http://ipv6int.net/systems/mac_os_x-ipv6.html
Mac OS X does not include
On Wed, 22 Sep 2010, Mark Smith wrote:
* Assuming a baseline of DNS being the only additional parameter over
addresses, you'd end up with -
o RA/SLAAC/RA DNS
I never supported RA DNS, I think it is a genuinely bad idea.
o RA/SLAAC/Stateless DHCPv6
o RA/Stateful DHCPv6
o Stateful DHCPv6
also, do not underestimate the co$t of the of operational change to move
from dhcp4 to nd/ra. folk who want to keep dns and ip audit may have to
go static without dhcp6. another non-trivial barrier to ipv6 deployment.
Randy, could you elaborate please? Not sure I see what you are getting
On Wed, 2010-09-22 at 07:01 -0400, Randy Bush wrote:
also, do not underestimate the co$t of the of operational change to move
from dhcp4 to nd/ra. folk who want to keep dns and ip audit may have to
go static without dhcp6. another non-trivial barrier to ipv6 deployment.
Randy, could you
On Wed, 22 Sep 2010, Karl Auer wrote:
Hm. Any host can take an address in its subnet - i.e. bypass DHCP. This
is as true of IPv6 as it is of IPv4. Any host that does SLAAC is
bypassing DHCPv6. So something has to watch the DHCP traffic and
dynamically permit addresses that have been allocated
On Wed, Sep 22, 2010 at 9:28 AM, Karl Auer ka...@biplane.com.au wrote:
On Wed, 2010-09-22 at 07:01 -0400, Randy Bush wrote:
also, do not underestimate the co$t of the of operational change to move
from dhcp4 to nd/ra. folk who want to keep dns and ip audit may have to
go static without
On Wed, 22 Sep 2010, Christopher Morrow wrote:
I can see that in the ipv6 world I'd want to do the same sort of thing,
assign addresses (and retain the capability to shift dns, tftp, wins,
etc) around from a central control point. I'd also like to not have
random things plugged into my LAN
In your previous mail you wrote:
As far as I know Apple doesn't support DHCPv6 at all.
= things are not so simple, i.e., I have a concern about the 'at all':
- Apple doesn't provide DHCPv6 (client, server or relay) in its
MacOS X distrib (this can change but on the MacOS X 10.6.4 I am
Le 21/09/2010 00:49, Brian E Carpenter a écrit :
On 2010-09-20 17:31, Mikael Abrahamsson wrote:
On Mon, 20 Sep 2010, Brian E Carpenter wrote:
Thanks for that. Now, what is needed for those techniques to be
fully deployable for IPv6, except work by the vendor(s)? Is
there any work needed on
On Wed, 22 Sep 2010 15:49:10 +0200 (CEST)
Mikael Abrahamsson swm...@swm.pp.se wrote:
On Wed, 22 Sep 2010, Christopher Morrow wrote:
I can see that in the ipv6 world I'd want to do the same sort of thing,
assign addresses (and retain the capability to shift dns, tftp, wins,
etc) around
On Wed, 22 Sep 2010, Benny Amorsen wrote:
If you want to give customers public IPv4 addresses and they each get
their own broadcast domain, you will have to give them 4 public IPv4
addresses per 1 usable address.
No, you don't. RFC3069.
I deployed one-vlan-per-customer-subvlan with a shared
On Thu, 23 Sep 2010, Mark Smith wrote:
If your concerns about end-node trust are as strong as they seem to be,
wouldn't you be using 802.1x link layer authentication to identify and
track the end-user? Wouldn't that be a much more effective mechanism to
track who was attached to the network,
On Tue, 21 Sep 2010, Ole Troan wrote:
I don't understand what you mean when you say ND isn't needed.
basic ND has this set of functions:
Router Discovery
Prefix Discovery
Parameter Discovery
Address Autoconfiguration
Address resolution
Next-hop determination
Neighbor
Mikael,
I don't understand what you mean when you say ND isn't needed.
basic ND has this set of functions:
Router Discovery
Prefix Discovery
Parameter Discovery
Address Autoconfiguration
Address resolution
Next-hop determination
Neighbor Unreachability Detection
On Tue, 21 Sep 2010, Ole Troan wrote:
in IPv4 access networks you do ARP from the CPE at least. how did you
intend for the CPE to learn the default router's mac address? glean it
from DHCP?
Yes.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
On 21/09/10 3:41 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Tue, 21 Sep 2010, Brian E Carpenter wrote:
I think the technical issue there is that ND and RA were designed as a
package, and you certainly can't run without ND.
Well, the DHCPv6 standard can be changed to hand out
On Tue, 21 Sep 2010, Hesham Soliman wrote:
= Before getting into the merits of your idea, why do you want to do
that? A pointer to some requirements or an email with the foreseen
benefits would be useful.
I mentioned it earlier in this thread (about 8 messages back), please see
the message
On 21/09/10 9:36 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Tue, 21 Sep 2010, Hesham Soliman wrote:
= Before getting into the merits of your idea, why do you want to do
that? A pointer to some requirements or an email with the foreseen
benefits would be useful.
I mentioned it
On Tue, 21 Sep 2010, Rémi Després wrote:
It seems to be too late anyway:
- A LAN without ND/RA wouldn't support currently existing hosts
Why not? DHCP could populate the neighbour table with very long lifetime?
The only change I see would be for the operation of DHCPv6 to always run
if
Mikael Abrahamsson:
Why not? DHCP could populate the neighbour table with very
long lifetime?
The only change I see would be for the operation of DHCPv6 to
always run
if there isn't any response to RS and no RA is seen.
Perhaps some minor changes need to be made to allow for
On Tue, 21 Sep 2010, Manfredi, Albert E wrote:
I think your idea makes most sense in cases where Internet access is
provided via cable head-ends or PONs. Where everything from customer
premises has to go through the head-end anyway. Yes, the need for ND in
this particular case is probably
Thanks for the explanation.
That's still too much a change IMHO.
Regards,
RDRD
Le 21 sept. 2010 à 17:45, Mikael Abrahamsson a écrit :
On Tue, 21 Sep 2010, Rémi Després wrote:
It seems to be too late anyway:
- A LAN without ND/RA wouldn't support currently existing hosts
Why not? DHCP
On 2010-09-22 03:00, Randy Bush wrote:
Well, I think what would help is to be able to run a DHCPv6 only
environment without RA/RS, it would also help if one didn't need NS
either. The whole L2 environment would need a lot less code, it
basically would only need to be able to filter the above
I'm not against new-and-better, and I have some spare Token Ring PCMCIA
cards if you need them, but we already have an IPv6 legacy. Mikael
is arguing for a mode in which there is no ND/RA traffic whatever,
so that layer-violation code in layer 2 doesn't have to watch out
for it. That isn't
no one is arguing nd/ra be removed entirely, as subnet anycast should be.
the argument is that there are environments where it is not needed and
dhcp should be able to be used in its place.
That's reasonable. There are cases where auto configuration does not work well.
A centrally
no one is arguing nd/ra be removed entirely, as subnet anycast should be.
the argument is that there are environments where it is not needed and
dhcp should be able to be used in its place.
That's reasonable. There are cases where auto configuration does not
work well. A centrally
On Tue, 2010-09-21 at 21:10 -0400, Randy Bush wrote:
also, do not underestimate the co$t of the of operational change to move
from dhcp4 to nd/ra. folk who want to keep dns and ip audit may have to
go static without dhcp6. another non-trivial barrier to ipv6 deployment.
Randy, could you
I agree. You want this minor change to be done in all host stacks. At this
stage IMO it's way too late. I'm dealing with some vendors now and I don't
hear any complaints about supporting ND in their routers/switches, that's
anecdotal but we didn't see this on the mailing list either. I can't see
On Wed, 22 Sep 2010, Hesham Soliman wrote:
I agree. You want this minor change to be done in all host stacks. At this
stage IMO it's way too late. I'm dealing with some vendors now and I don't
hear any complaints about supporting ND in their routers/switches, that's
anecdotal but we didn't see
On 22/09/10 3:21 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Wed, 22 Sep 2010, Hesham Soliman wrote:
I agree. You want this minor change to be done in all host stacks. At this
stage IMO it's way too late. I'm dealing with some vendors now and I don't
hear any complaints about
On Wed, 22 Sep 2010, Hesham Soliman wrote:
ND is a show-stopper or even delaying any router vendor.
Nobody is saying a router shouldn't do ND. What we're saying is that an L2
network shouldn't have to do ND inspection, so it should be possible to
make things work without ND.
--
Mikael
On Wed, 22 Sep 2010, Hesham Soliman wrote:
= I understand that, but I think that to make this work you will need
to do that with zero modifications to the host's IPv6 stack. I don't
think you can count on people modifying their host implementations to
support this scenario.
Do you count the
On 22/09/10 3:30 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Wed, 22 Sep 2010, Hesham Soliman wrote:
= I understand that, but I think that to make this work you will need
to do that with zero modifications to the host's IPv6 stack. I don't
think you can count on people modifying
On Wed, 22 Sep 2010, Hesham Soliman wrote:
On 22/09/10 3:30 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Wed, 22 Sep 2010, Hesham Soliman wrote:
= I understand that, but I think that to make this work you will need
to do that with zero modifications to the host's IPv6 stack. I don't
On 22/09/10 3:39 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Wed, 22 Sep 2010, Hesham Soliman wrote:
On 22/09/10 3:30 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Wed, 22 Sep 2010, Hesham Soliman wrote:
= I understand that, but I think that to make this work you will need
Mikael,
[changing subject as this has departed from discussing the RS mark draft]
I think the technical issue there is that ND and RA were designed as a
package, and you certainly can't run without ND.
Well, the DHCPv6 standard can be changed to hand out information so ND isn't
needed.
On Mon, 20 Sep 2010, Brian E Carpenter wrote:
Thanks for that. Now, what is needed for those techniques to be
fully deployable for IPv6, except work by the vendor(s)? Is there
any work needed on the basic IPv6 standards?
Well, I think what would help is to be able to run a DHCPv6 only
Hi Ole,
On 10-09-13 03:16 AM, Ole Troan wrote:
4) full IPv6 support without DHCPv6
5) full IPv6 support with DHCPv6
by partly broken I mean lacking dual stack / IPv4/IPv6 multihoming support. i.e
happy eyeballs or having other serious short comings. I do not want to enable
IPv6 on hosts
Hi Ole,
On 10-09-13 05:20 AM, Ole Troan wrote:
Olaf,
let us say we have 5 classes of host implementations:
1) IPv4 only and those which will never be upgraded with IPv6 support
2) partly broken IPv6 support and without DHCPv6
3) partly broken IPv6 support with DHCPv6
4) full IPv6 support
Suresh,
4) full IPv6 support without DHCPv6
5) full IPv6 support with DHCPv6
by partly broken I mean lacking dual stack / IPv4/IPv6 multihoming support.
i.e happy eyeballs or having other serious short comings. I do not want to
enable IPv6 on hosts implementations that e.g have 75 second
Krishnan
Cc: olaf.bonn...@telekom.de; ipv6@ietf.org
Subject: Re: AW: New version available
Suresh,
4) full IPv6 support without DHCPv6
5) full IPv6 support with DHCPv6
by partly broken I mean lacking dual stack / IPv4/IPv6
multihoming support. i.e happy eyeballs or having other
Sursh,
let us say we have 5 classes of host implementations:
1) IPv4 only and those which will never be upgraded with IPv6 support
2) partly broken IPv6 support and without DHCPv6
3) partly broken IPv6 support with DHCPv6
4) full IPv6 support without DHCPv6
5) full IPv6 support with
...@ietf.org [mailto:ipv6-boun...@ietf.org] On
Behalf Of Ole Troan
Sent: Tuesday, September 14, 2010 10:32 AM
To: Suresh Krishnan
Cc: olaf.bonn...@telekom.de; ipv6@ietf.org
Subject: Re: AW: New version available
Suresh,
4) full IPv6 support without DHCPv6
5) full IPv6 support with DHCPv6
: olaf.bonn...@telekom.de; ipv6@ietf.org
Subject: Re: AW: New version available
XP has limitations but is still usable if IPv6 is enabled.
On 9/14/10 10:40 AM, Jason Weil jason.w...@cox.com wrote:
The whole lack of IPv6 transport in XP for DNS kinda fails
the 'full IPv6
support
To: Weil, Jason (CCI-Atlanta); otr...@employees.org; Suresh Krishnan
Cc: olaf.bonn...@telekom.de; ipv6@ietf.org
Subject: Re: AW: New version available
XP has limitations but is still usable if IPv6 is enabled.
On 9/14/10 10:40 AM, Jason Weil jason.w...@cox.com wrote:
The whole lack
Hi Jason,
On 10-09-14 10:50 AM, jason.w...@cox.com wrote:
True.
Usable in a dual-stack environment.
Not usable IPv6-only.
Absolutely right. The BBF architecture in question is dual-stack.
Thanks
Suresh
IETF IPv6 working
XP has limitations but is still usable if IPv6 is enabled.
on a dual-stack lan, or one with a specific dns-over-v4 crutch for xp
randy
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests:
I was referring to dual stack.
On 9/14/10 12:08 PM, Randy Bush ra...@psg.com wrote:
XP has limitations but is still usable if IPv6 is enabled.
on a dual-stack lan, or one with a specific dns-over-v4 crutch for xp
randy
=
John Jason Brzozowski
...@69706e6720323030352d30312d31340a.nosense.org; ipv6@ietf.org; f...@cisco.com
Betreff: Re: New version available
On 10 September 2010 12:52, olaf.bonn...@telekom.de wrote:
PPP is not used here. There are numerous different
deployment models, PPP
is an expensive one that should be avoided unless
Olaf,
thx for your comments. I nearly forgot that an ISP has to offer its customers
a good service, thx for reminding me ;-).
I'm just inserting as an answer a sentence, I found in an email posted by Tom
Petch on this mailing list in another context:
Tom Petch wrote on Fr 10.09.2010
On Mon, 13 Sep 2010, Ole Troan wrote:
4) full IPv6 support without DHCPv6
we don't care about 1. we do _not_ want to deliver IPv6 service to 2 +
3. so the problematic one is 4. does anyone know of any class 4 IPv6
implementation?
I'd imagine cany class 4 IPv6 devices will quickly be pushed
...@gmail.com; ipv6@ietf.org
Betreff: Re: AW: New version available
Olaf,
--
...
--
so which solutions do we have:
1) only support DHCP on the BBF link-layer in the N:1 VLAN case.
this will affect some legacy host implementations in the
case where the customer has
...@gmail.com]
*Gesendet:* Freitag, 10. September 2010 16:14
*An:* Bonneß, Olaf
*Cc:* roberta.magli...@telecomitalia.it; swm...@swm.pp.se;
i...@69706e6720323030352d30312d31340a.nosense.org; ipv6@ietf.org;
f...@cisco.com
*Betreff:* Re: New version available
On 10 September 2010 12:52, olaf.bonn
Olaf,
let us say we have 5 classes of host implementations:
1) IPv4 only and those which will never be upgraded with IPv6 support
2) partly broken IPv6 support and without DHCPv6
3) partly broken IPv6 support with DHCPv6
4) full IPv6 support without DHCPv6
5) full IPv6 support with DHCPv6
Hi Woj,
thx for your answer. I think, that you 've misunderstood / misinterpreted my
words. I'm sure that you know very well that a service provider wants to change
as little as possible and that he can not influence / modify all host
implementations on customer site.
Regarding I-D
On Sun, 12 Sep 2010 07:29:10 +0200 (CEST)
Mikael Abrahamsson swm...@swm.pp.se wrote:
On Sun, 12 Sep 2010, Mark Smith wrote:
So my question was how would you solve it (architecturally)?
Layer 2 devices inspecting traffic isn't architecturally acceptable
because it's a layer violation,
On Sun, 12 Sep 2010 11:58:45 +0200 (CEST)
Mikael Abrahamsson swm...@swm.pp.se wrote:
On Sun, 12 Sep 2010, Mark Smith wrote:
On Sun, 12 Sep 2010 07:29:10 +0200 (CEST)
Mikael Abrahamsson swm...@swm.pp.se wrote:
On Sun, 12 Sep 2010, Mark Smith wrote:
So my question was how would you
On Sun, 12 Sep 2010, Mark Smith wrote:
So I accept layer violations to perform some of these functions, but I
think it'd be preferable if they could be avoided.
Of course it is preferrable if they can be avoided.
Problem is that the method you're suggesting to solve this with, is not
On Sep 12, 2010, at 4:01 AM, Mark Smith wrote:
What I said was, and I'll highlight the key word,
Layer 2 devices inspecting traffic isn't *architecturally* acceptable
because it's a layer violation
The best place to fix IPv6 issues in in IPv6.
well, yes, but...
let me give you one
On Sat, 11 Sep 2010, Mark Smith wrote:
How would you solve the problem? If you give end-nodes the ability to
Exactly the way it has been done for IPv4 with the mechanisms I've given
examples of before. L2 devices look at DHCPv6 etc and then enforce policy
accordingly. The thing here is that
On Sep 11, 2010, at 3:06 PM, Mikael Abrahamsson wrote:
On Sat, 11 Sep 2010, Mark Smith wrote:
How would you solve the problem? If you give end-nodes the ability to
Exactly the way it has been done for IPv4 with the mechanisms I've given
examples of before. L2 devices look at DHCPv6 etc
On Sat, 11 Sep 2010, Fred Baker wrote:
If I may make a humble request - could we get back to work, please?
Good post.
I guess I've been part of the bashing. It's a fine line between saying
that things haven't been done to solve current problems and there is a lot
of improvement to do, and
Doug,
But it's not. ... We _really_ want to get this right NOW. Adding more
kludges so that we can Just get it deployed is actually going to
make life (and future deployment) harder down the road, not easier.
Agreed so far.
Suresh wants to support a particular type of a deployment, and it
On Sat, 11 Sep 2010 08:06:39 +0200 (CEST)
Mikael Abrahamsson swm...@swm.pp.se wrote:
On Sat, 11 Sep 2010, Mark Smith wrote:
How would you solve the problem? If you give end-nodes the ability to
Exactly the way it has been done for IPv4 with the mechanisms I've given
examples of before.
On Sun, 12 Sep 2010, Mark Smith wrote:
So my question was how would you solve it (architecturally)?
Layer 2 devices inspecting traffic isn't architecturally acceptable
because it's a layer violation,
+1 on what Steinar Haug wrote.
Serious disconnect between map and reality here, Mark.
--
...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Mikael
Abrahamsson
Sent: giovedì 9 settembre 2010 17.10
To: Mark Smith
Cc: ipv6@ietf.org; Fred Baker
Subject: Re: New version available
On Thu, 9 Sep 2010, Mark Smith wrote:
I don't know about other vendors, however Cisco have a model of SLAAC
in the RA PIO is a valid solution.
Best Regards,
Roberta
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf
Of Mikael Abrahamsson
Sent: giovedì 9 settembre 2010 17.10
To: Mark Smith
Cc: ipv6@ietf.org; Fred Baker
Subject: Re: New version available
On Fri, 10 Sep 2010, Maglione Roberta wrote:
PPP is not used here. There are numerous different deployment models, PPP
is an expensive one that should be avoided unless there is serious use for
it.
While it is true that PPP is not used here, I won't say that PPP should
be avoided. PPP is a
On Fri, 10 Sep 2010, Tina TSOU wrote:
Some operators have serious use for PPPoE in large scale. It is a tradeoff
for them to decide whether it is expensive or not from the whole picture
point of view.
Yes. I don't see where I said they shouldn't. I said it was expensive, I
didn't deny there
-Original Message-
From: Mikael Abrahamsson [mailto:swm...@swm.pp.se]
Sent: venerdì 10 settembre 2010 12.10
To: Maglione Roberta
Cc: Mark Smith; ipv6@ietf.org; Fred Baker
Subject: RE: New version available
On Fri, 10 Sep 2010, Maglione Roberta wrote:
PPP is not used here
PPP is not used here. There are numerous different deployment models, PPP
is an expensive one that should be avoided unless there is serious use for
it.
While it is true that PPP is not used here, I won't say that PPP should be
avoided.
PPP is a valid and widely deployed model in DSL
PPP is not used here. There are numerous different
deployment models, PPP
is an expensive one that should be avoided unless there is
serious use for
it.
While it is true that PPP is not used here, I won't say that
PPP should be avoided.
PPP is a valid and widely deployed model in
Some of the discussion has gone into the history of IPv6 design, what
configuration model was intended by the original designers as the right
one, and so on. I would suggest that while that's interesting, it may be
secondary to what we are discussing here.
Suresh wants to support a particular
On Fri, 10 Sep 2010, Jari Arkko wrote:
Host support is important because that is an area where neither the
IETF, any single vendor, or the DSL operators have any easy way to
change the situation. But it is of course by no means the only
constraint. The operators have their issues as well.
On 10 September 2010 12:52, olaf.bonn...@telekom.de wrote:
PPP is not used here. There are numerous different
deployment models, PPP
is an expensive one that should be avoided unless there is
serious use for
it.
While it is true that PPP is not used here, I won't say that
PPP
- Original Message -
From: Christopher Morrow christopher.mor...@gmail.com
To: Mikael Abrahamsson swm...@swm.pp.se
Cc: ipv6@ietf.org
Sent: Thursday, September 09, 2010 4:17 PM
this is a case where 'listen to how the network is operated today,
please.' is required I think. There are
On 9/10/2010 7:13 AM, Wojciech Dec wrote:
3. Set a bar on the minimum _CPE_ requirements that will be supported by
the network (ensuring connectivity) within the given scenarios, along
with potentially having a single configuration/provisioning method? An
example of this would be requiring a
On 9/10/2010 5:59 AM, Jari Arkko wrote:
Some of the discussion has gone into the history of IPv6 design, what
configuration model was intended by the original designers as the
right one, and so on. I would suggest that while that's interesting,
it may be secondary to what we are discussing here.
: September-08-10 2:27 PM
To: Joel M. Halpern
Cc: Narten Thomas; IPv6 WG Mailing List; Suresh Krishnan
Subject: Re: New version available (Was Re: Consensus call on
adopting:draft-krishnan-6man-rs-mark-06.txt)
Joel - only some operators have decided that they need to allow for the
corner case
Hi Suresh,
Suresh Krishnan wrote:
Hi Julien,
On 10-09-08 07:43 PM, Laganier, Julien wrote:
Thomas Narten wrote:
[...]
RAs/SLAAC work very well when RAs can be multicast to *all* nodes on
a link, and *all* nodes receive exactly the same information about
prefixes and SLAAC. I.e,
On Fri, 10 Sep 2010 07:34:42 +0200 (CEST)
Mikael Abrahamsson swm...@swm.pp.se wrote:
On Fri, 10 Sep 2010, Brian E Carpenter wrote:
I'm sure there are a lot in the IETF that agrees with you that they
don't understand why it's a problem, because the IETF has historically
been totally
Hi Doug,
Just clarifying one technical point that you raised.
On 10-09-10 03:04 PM, Doug Barton wrote:
Two responses. If we can't expect the hosts to be changed in order for
this to work, how do we expect them to send clever new RS messages even
if the draft is adopted (or perhaps I'm
On 2010-09-11 12:24, Mark Smith wrote:
On Fri, 10 Sep 2010 07:34:42 +0200 (CEST)
Mikael Abrahamsson swm...@swm.pp.se wrote:
On Fri, 10 Sep 2010, Brian E Carpenter wrote:
I'm sure there are a lot in the IETF that agrees with you that they
don't understand why it's a problem, because the
On Sep 11, 2010, at 1:06 AM, t.petch wrote:
So the onus is on operators to turn their good business reasons into
engineering problems, eg as a requirements RFC, that the IETF will then solve.
Thanks. I gather the operators have gotten a lot of bashing from IETF
participants in the past; I'm
So the onus is on operators to turn their good business reasons into
engineering problems, eg as a requirements RFC, that the IETF will
then solve.
no. it is the duty of operators to turn their business plans into
operational practice, deliver packets, and charge the customers.
and it is for
On Sep 11, 2010, at 2:00 PM, Randy Bush wrote:
So the onus is on operators to turn their good business reasons into
engineering problems, eg as a requirements RFC, that the IETF will
then solve.
no. it is the duty of operators to turn their business plans into
operational practice,
Suresh,
There are still unanswered questions..
Comments inline ...
--
Shree
-Original Message-
From: Suresh Krishnan [mailto:suresh.krish...@ericsson.com]
[..snip..]
1. Prefix Lifetime Binding/Expiry..
Unlike DHCP there is no mechanism with SLAAC for a host (client) to
On Thu, 9 Sep 2010 07:43:35 +0200 (CEST)
Mikael Abrahamsson swm...@swm.pp.se wrote:
On Thu, 9 Sep 2010, Brian E Carpenter wrote:
I can't see why that would be a problem for an operator who uses DHCPv6
as their supported mechanism.
I'm sure there are a lot in the IETF that agrees with
Suresh,
5. Creating an alternative to DHCPv6 ?
One SLAAC is defined to do functionality similar to DHCP (including per
host prefixes/options)
how long before options are added so SLAAC becomes an alternative to
DHCPv6 ?
The goal is not to come up with an alternative to DHCPv6. The
On Sep 9, 2010, at 7:29 PM, Mark Smith wrote:
SAVI and things like SeND are beneficial halfway measures, avoiding full
quarantining.
I would generally agree.
Just like being at a cocktail party, there is no way to know just how looped a
neighbor is or how it will behave in that condition.
- the network never knows when a host detaches, because the host does not
send a goodbye RS. As a result, if a prefix were allocated by the network
for the
host, it cannot be returned to a free prefix pool based on signaling from the
host.
Are you planning to collect unused prefix based on an
On Thu, 9 Sep 2010, Mark Smith wrote:
So why aren't operators involving themselves more?
I don't know. I've been involving myself in IETF the past year or so, but
it's not something I can spend huge amounts of time on.
I've seen a number of invitations for feedback and comments on IETF in
1 - 100 of 153 matches
Mail list logo
