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
Hi,
Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org writes:
I think the kernel space/user space decision is about ubiquity. When it
RAs/SLAAC is implemented in the kernel, then it's always there. If
DHCPv6 had been implemented in kernels then we wouldn't have the
availability
On Thu, 23 Sep 2010 10:32:11 +0200
a...@natisbad.org (Arnaud Ebalard) wrote:
Hi,
Mark Smith i...@69706e6720323030352d30312d31340a.nosense.org writes:
I think the kernel space/user space decision is about ubiquity. When it
RAs/SLAAC is implemented in the kernel, then it's always there.
On Wed, 22 Sep 2010, Hesham Soliman wrote:
= But you're saying that as an operator need, when in fact your rationale
is to reduce vendor code. Is any vendor complaining about this? Is this an
Well, yes, I want to reduce vendor code and to simplify the deployment. In
my deployment model there
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 22/09/10 3:56 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Wed, 22 Sep 2010, Hesham Soliman wrote:
= But you're saying that as an operator need, when in fact your rationale
is to reduce vendor code. Is any vendor complaining about this? Is this an
Well, yes, I want to reduce
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
But you're saying that as an operator need, when in fact your
rationale is to reduce vendor code. Is any vendor complaining about
this?
your monotonically increasing bug count results in my operational need.
randy
IETF IPv6
Hi,
Mikael Abrahamsson swm...@swm.pp.se writes:
On Wed, 22 Sep 2010, Mark Smith wrote:
I never supported RA DNS, I think it is a genuinely bad idea.
And you probably have some arguments to share ...
Cheers,
a+
IETF IPv6
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
Hi,
Mikael Abrahamsson swm...@swm.pp.se writes:
On Wed, 22 Sep 2010, Arnaud Ebalard wrote:
I never supported RA DNS, I think it is a genuinely bad idea.
And you probably have some arguments to share ...
DHCPv6 stateless seem more suited to put all these options in, DNS is
just one
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
In your previous mail you wrote:
Not necessarily handled in kernel space:
- One of the first *BSD (INRIA) ipv6 implementation handled RA in
userspace
- Also IBM AIX 4.x handled RA in user space.
= the second is a consequence of the first. BTW I wrote a full ND in
user mode for
Le 21/09/2010 07:55, Ole Troan a écrit :
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
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 17:33:37 +0200
a...@natisbad.org (Arnaud Ebalard) wrote:
Hi,
Mikael Abrahamsson swm...@swm.pp.se writes:
On Wed, 22 Sep 2010, Arnaud Ebalard wrote:
I never supported RA DNS, I think it is a genuinely bad idea.
And you probably have some arguments to share ...
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 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
On 9/21/2010 4:16 PM, Brian E Carpenter wrote:
we already have an IPv6 legacy
As much as I wish it were otherwise, I don't think there is yet enough
of a deployment at this point to really make this a show-stopper.
But even if we do, I don't see any reason we couldn't have a no-ND
solution
On 2010-09-22 14:03, Doug Barton wrote:
On 9/21/2010 4:16 PM, Brian E Carpenter wrote:
we already have an IPv6 legacy
As much as I wish it were otherwise, I don't think there is yet enough
of a deployment at this point to really make this a show-stopper.
But even if we do, I don't see any
On 9/21/2010 7:29 PM, Brian E Carpenter wrote:
On 2010-09-22 14:03, Doug Barton wrote:
On 9/21/2010 4:16 PM, Brian E Carpenter wrote:
we already have an IPv6 legacy
As much as I wish it were otherwise, I don't think there is yet enough
of a deployment at this point to really make this a
On Tue, 21 Sep 2010 19:03:13 -0700
Doug Barton do...@dougbarton.us wrote:
On 9/21/2010 4:16 PM, Brian E Carpenter wrote:
we already have an IPv6 legacy
As much as I wish it were otherwise, I don't think there is yet enough
of a deployment at this point to really make this a show-stopper.
On Wed, 22 Sep 2010, Brian E Carpenter wrote:
RS packets. As I understood Mikael, he wanted to remove all snooping
of such packets from layer 2 devices. Well, if you do that, those
packets will still be there, and if they are a security risk, the
risk will still be there. And you'd probably
On Wed, 22 Sep 2010, Mark Smith wrote:
Why aren't the still-large percentage of the operator community not
bothering to contribute?
This has already been re-iterated time and time again. Operators are
generally not protocol architects, they are in the business of building
and maintaining
They are already optional. Those people who don't want to use ND/RAs are
likely to already have knobs to switch them off (Cisco switch off RAs by
default on some interface types already) and will have static
configuration mechanisms.
.. and what (I, and others) are saying is that we would
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.
43 matches
Mail list logo
