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" wrote:
>On Oct 20, 2010, at 05:25, Thomas Narten wrote:
>
>> Thanks for this info. Clarificat
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 suppor
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 pol
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
> > Unless you want to assign different default routers to different
> > clients. I don't know if this should be taken into account, but
> > it is a possibility...
>
> I'd wonder if there are examples of that being done in IPv4. I can't
> really think of a real world situation I've experienced in
In your letter dated Thu, 23 Sep 2010 13:38:11 +0200 (CEST) you wrote:
>On Thu, 23 Sep 2010, Philip Homburg wrote:
>> I did not mean to trust the CPE. I mean that whatever layer violation
>> you want done, can be hidden in the CPE instead of exposing it to the
>> host (or router) behind it.
>
>I
On Thu, 23 Sep 2010, Philip Homburg wrote:
I did not mean to trust the CPE. I mean that whatever layer violation
you want done, can be hidden in the CPE instead of exposing it to the
host (or router) behind it.
I don't see how this would work/help. I cannot trust the CPE, so I still
need to
In your letter dated Thu, 23 Sep 2010 13:03:35 +0200 (CEST) you wrote:
>On Thu, 23 Sep 2010, Philip Homburg wrote:
>> The CPE can then for example continue sending RS messages, and can
>> terminate NS messages by always returning the concentrator's MAC
>> address, etc.
>
>One cannot trust equipme
On Thu, 23 Sep 2010 12:57:12 +0200
Sander Steffann wrote:
> Hi,
>
> > By setting the Router Lifetime to 0 in the RA, that'd stop the router
> > being used as a default router. However, then you'd need a DHCPv6
> > option to convey the default router. That still wouldn't eliminate the
> > need fo
On Thu, 23 Sep 2010, Philip Homburg wrote:
The CPE can then for example continue sending RS messages, and can
terminate NS messages by always returning the concentrator's MAC
address, etc.
One cannot trust equipment under customer physical control. Ask the
creators of Sony PS3 and Microsoft
Hi,
> By setting the Router Lifetime to 0 in the RA, that'd stop the router
> being used as a default router. However, then you'd need a DHCPv6
> option to convey the default router. That still wouldn't eliminate the
> need for the RA though, as it is still being used to express the
> address conf
On Thu, 23 Sep 2010 07:33:24 +0200 (CEST)
Mikael Abrahamsson wrote:
> 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
In your letter dated Thu, 23 Sep 2010 07:33:24 +0200 (CEST) you wrote:
>I'm talking about ETTH, one port in an L2 switch is a household. I know
>what port goes to each household, so "trust" is not the issue.
>
>In IPv4 I hand out an IP address and I know to what port (option 82) this
>IP address
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, w
On Wed, 22 Sep 2010 15:49:10 +0200 (CEST)
Mikael Abrahamsson 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 from a ce
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
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 get
On Wed, Sep 22, 2010 at 9:28 AM, Karl Auer 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 dhcp6. ano
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, 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,
>> 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 getti
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 Onl
On Wed, 22 Sep 2010 12:10:41 +0200 (CEST)
Mikael Abrahamsson wrote:
> 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 DECEMB
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 DHC
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 ne
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 à 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 w
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 el
>> 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 c
> 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 config
> 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'
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
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
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
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 Unreac
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
> need
36 matches
Mail list logo
