Mailing List Archive: nsp: ipv6

DHCPv6 Confirm in DOCSIS networks

Index | Next | Previous | View Threaded

tore.anderson at redpill-linpro

May 18, 2012, 1:03 AM

Post #1 of 18 (988 views)
Permalink

DHCPv6 Confirm in DOCSIS networks

My cable provider just got included me in their IPv6 pilot. One of the
first things I noticed when testing (using a computer directly attached
to the cable modem) was that DHCPv6 Confirm messages went unanswered.
The first time I connected went fast, while all subsequent connections
(e.g. after resuming from suspend) was slow, as the Confirm request had
to time out before information from the cached lease was used.

I understood from my provider that the likely cause was that their Cisco
CNR DHCPv6 server did not support DHCPv6 Confirm, and they also pointed
me to the following UNH-IOL document, which says ŤTransmission of DHCPv6
Confirm message is not expected on a DOCSIS WAN networkť:

https://www.iol.unh.edu/services/testing/ipv6/grouptest/white_papers/CPE_IPv6_Test_Event_Whitepaper.pdf

This strikes me as rather strange - as far as I can tell, the DHCPv6
client has no way of determining if the Ethernet interface is running on
is connected to a DOCSIS modem or something else, so I don't see how it
could possibly selectively disable the use of Confirm in the case of DOCSIS.

Does anyone have more information on why DHCPv6 Confirm wouldn't be
expected and supported in DOCSIS networks? (Does it work in Comcast's
network?)

--
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com

otroan at employees

May 18, 2012, 1:19 AM

Post #2 of 18 (959 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

Tore,

> My cable provider just got included me in their IPv6 pilot. One of the
> first things I noticed when testing (using a computer directly attached
> to the cable modem) was that DHCPv6 Confirm messages went unanswered.
> The first time I connected went fast, while all subsequent connections
> (e.g. after resuming from suspend) was slow, as the Confirm request had
> to time out before information from the cached lease was used.
>
> I understood from my provider that the likely cause was that their Cisco
> CNR DHCPv6 server did not support DHCPv6 Confirm, and they also pointed
> me to the following UNH-IOL document, which says ŤTransmission of DHCPv6
> Confirm message is not expected on a DOCSIS WAN networkť:
>
> https://www.iol.unh.edu/services/testing/ipv6/grouptest/white_papers/CPE_IPv6_Test_Event_Whitepaper.pdf

that's not quite what the document says.

> This strikes me as rather strange - as far as I can tell, the DHCPv6
> client has no way of determining if the Ethernet interface is running on
> is connected to a DOCSIS modem or something else, so I don't see how it
> could possibly selectively disable the use of Confirm in the case of DOCSIS.
>
> Does anyone have more information on why DHCPv6 Confirm wouldn't be
> expected and supported in DOCSIS networks? (Does it work in Comcast's
> network?)

I'm probably at fault for why Confirm is a bit of an ugly duckling in access network, by stating in RFC3633 that Confirm isn't used for IA_PD (Renew is used instead). we're changing that with http://tools.ietf.org/html/draft-troan-dhc-dhcpv6-stateful-issues-00

in any case, CNR handles Confirm and when you only use IA_NA as you do, using Confirm is perfectly fine.

cheers,
Ole

tore.anderson at redpill-linpro

May 18, 2012, 1:31 AM

Post #3 of 18 (959 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

Hi,

* Ole Trřan

>> I understood from my provider that the likely cause was that their
>> Cisco CNR DHCPv6 server did not support DHCPv6 Confirm, and they
>> also pointed me to the following UNH-IOL document, which says
>> ŤTransmission of DHCPv6 Confirm message is not expected on a DOCSIS
>> WAN networkť:
>>
>> https://www.iol.unh.edu/services/testing/ipv6/grouptest/white_papers/CPE_IPv6_Test_Event_Whitepaper.pdf
>
>>
> that's not quite what the document says.

It's a verbatim quote, see page 8. Do I understand it incorrectly?

> I'm probably at fault for why Confirm is a bit of an ugly duckling in
> access network, by stating in RFC3633 that Confirm isn't used for
> IA_PD (Renew is used instead). we're changing that with
> http://tools.ietf.org/html/draft-troan-dhc-dhcpv6-stateful-issues-00
>
> in any case, CNR handles Confirm and when you only use IA_NA as you
> do, using Confirm is perfectly fine.

The Confirm was for IA_NA, indeed. Hadn't tested PD yet. So if the CNR
is supposed to support it, there must be some other reason why it
doesn't work. Hmm. I'll check back with my provider, thanks!

Best regards,
--
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com

dr at cluenet

May 18, 2012, 2:05 AM

Post #4 of 18 (955 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

On Fri, May 18, 2012 at 10:31:01AM +0200, Tore Anderson wrote:
> The Confirm was for IA_NA, indeed. Hadn't tested PD yet. So if the CNR
> is supposed to support it, there must be some other reason why it
> doesn't work. Hmm. I'll check back with my provider, thanks!

Wild guess: check wether the client accidentially unicasts the CONFIRM
request... I think I saw such brokeness somewhere, some time ago (don't
remember vendor and circumstances).

Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr [at] cluenet -- dr [at] IRCne -- PGP: 0xA85C8AA0

tore.anderson at redpill-linpro

May 18, 2012, 2:16 AM

Post #5 of 18 (963 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

* Daniel Roesen

> Wild guess: check wether the client accidentially unicasts the CONFIRM
> request... I think I saw such brokeness somewhere, some time ago (don't
> remember vendor and circumstances).

Hi,

It's sent to the ff02::1:2 multicast address. I'm using ISC dhclient
version 4.2.3-8.P2, the standard one included in Fedora 16. You can see
the two connections in the PCAP @ http://fud.no/get-init.pcap. Frames
1-7 is the initial connection with no cached lease, 8-13 is after
reseating the Ethernet cable betwen my laptop and the modem. I don't see
anything wrong with the exchange, but maybe you have better eyes...

--
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com

ek at google

May 18, 2012, 5:29 PM

Post #6 of 18 (945 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

> It's sent to the ff02::1:2 multicast address. I'm using ISC dhclient
> version 4.2.3-8.P2, the standard one included in Fedora 16. You can see
> the two connections in the PCAP @ http://fud.no/get-init.pcap. Frames
> 1-7 is the initial connection with no cached lease, 8-13 is after
> reseating the Ethernet cable betwen my laptop and the modem. I don't see
> anything wrong with the exchange, but maybe you have better eyes...

Please pardon my ignorance, but what's that second AdvertiseXID in
there? It has a different server identifier and assigns a different
address. The Confirms all seem to be for the address in the first
AdvertiseXID, not the 2nd.

Is this normal?

jjmbcom at gmail

May 18, 2012, 5:36 PM

Post #7 of 18 (947 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

Tore your CMTS could be dropping the CONFIRM message. I know of only one
CMTS that drops this type of message. The Cisco 10K.

On Friday, May 18, 2012, Erik Kline <ek [at] google> wrote:
>> It's sent to the ff02::1:2 multicast address. I'm using ISC dhclient
>> version 4.2.3-8.P2, the standard one included in Fedora 16. You can see
>> the two connections in the PCAP @ http://fud.no/get-init.pcap. Frames
>> 1-7 is the initial connection with no cached lease, 8-13 is after
>> reseating the Ethernet cable betwen my laptop and the modem. I don't see
>> anything wrong with the exchange, but maybe you have better eyes...
>
> Please pardon my ignorance, but what's that second AdvertiseXID in
> there? It has a different server identifier and assigns a different
> address. The Confirms all seem to be for the address in the first
> AdvertiseXID, not the 2nd.
>
> Is this normal?
>

--
===================================
John Jason Brzozowski
===================================

jjmbcom at gmail

May 18, 2012, 5:55 PM

Post #8 of 18 (946 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

Forgot to mentioned DHCPv6 CONFIRMs are supported on my network.

On Fri, May 18, 2012 at 4:03 AM, Tore Anderson <
tore.anderson [at] redpill-linpro> wrote:

> My cable provider just got included me in their IPv6 pilot. One of the
> first things I noticed when testing (using a computer directly attached
> to the cable modem) was that DHCPv6 Confirm messages went unanswered.
> The first time I connected went fast, while all subsequent connections
> (e.g. after resuming from suspend) was slow, as the Confirm request had
> to time out before information from the cached lease was used.
>
> I understood from my provider that the likely cause was that their Cisco
> CNR DHCPv6 server did not support DHCPv6 Confirm, and they also pointed
> me to the following UNH-IOL document, which says ŤTransmission of DHCPv6
> Confirm message is not expected on a DOCSIS WAN networkť:
>
>
> https://www.iol.unh.edu/services/testing/ipv6/grouptest/white_papers/CPE_IPv6_Test_Event_Whitepaper.pdf
>
> This strikes me as rather strange - as far as I can tell, the DHCPv6
> client has no way of determining if the Ethernet interface is running on
> is connected to a DOCSIS modem or something else, so I don't see how it
> could possibly selectively disable the use of Confirm in the case of
> DOCSIS.
>
> Does anyone have more information on why DHCPv6 Confirm wouldn't be
> expected and supported in DOCSIS networks? (Does it work in Comcast's
> network?)
>
> --
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com
>

--
===================================
John Jason Brzozowski
===================================

jjmbcom at gmail

May 18, 2012, 5:57 PM

Post #9 of 18 (949 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

The operator probably has two separate DHCPv6 servers running for
redundancy. As such, and in the absence of DHCPv6 failover support, both
servers will send an ADVERTISE. Does one server have a higher preference
value than the other?

John

On Fri, May 18, 2012 at 8:29 PM, Erik Kline <ek [at] google> wrote:

> > It's sent to the ff02::1:2 multicast address. I'm using ISC dhclient
> > version 4.2.3-8.P2, the standard one included in Fedora 16. You can see
> > the two connections in the PCAP @ http://fud.no/get-init.pcap. Frames
> > 1-7 is the initial connection with no cached lease, 8-13 is after
> > reseating the Ethernet cable betwen my laptop and the modem. I don't see
> > anything wrong with the exchange, but maybe you have better eyes...
>
> Please pardon my ignorance, but what's that second AdvertiseXID in
> there? It has a different server identifier and assigns a different
> address. The Confirms all seem to be for the address in the first
> AdvertiseXID, not the 2nd.
>
> Is this normal?
>

--
===================================
John Jason Brzozowski
===================================

ek at google

May 18, 2012, 6:01 PM

Post #10 of 18 (946 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

On 18 May 2012 17:57, John Jason Brzozowski <jjmbcom [at] gmail> wrote:
> The operator probably has two separate DHCPv6 servers running for
> redundancy. Â As such, and in the absence of DHCPv6 failover support, both
> servers will send an ADVERTISE. Â Does one server have a higher preference
> value than the other?

Oh right. And in DHCPv6 land you just pick one to reply to and that's
that (right?). Ignore me.

tore.anderson at redpill-linpro

May 19, 2012, 2:57 AM

Post #11 of 18 (947 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

Hi,

* John Jason Brzozowski

> Tore your CMTS could be dropping the CONFIRM message. I know of only >
one CMTS that drops this type of message. The Cisco 10K.

The CMTS has a Cisco MAC address, so it seems likely that this is the
reason why it doesn't work. Thanks - I'll discuss this with my provider.

> The operator probably has two separate DHCPv6 servers running for
> redundancy. As such, and in the absence of DHCPv6 failover support,
> both servers will send an ADVERTISE. Does one server have a higher
> preference value than the other?

No preference values are being transmitted in the ADVERTISE messages.
Hmm. I've had my PD prefix change on me once already, and that's the
probably the reason. Unlike my laptop, my HGW (a ZyXEL P2812) sends
RELEASE once its WAN port goes down, and starts the DHCPv6 client state
machine from scratch (with SOLICIT) once it comes back up. So I guess
that would mean it's a coin's toss whether I get back the same prefix I
had before, or if I get the prefix offered by the other DHCPv6 server.
Which is rather problematic, as the ZyXEL doesn't handle LAN renumbering
very well, so I get left with stale and non-working addresses from the
old prefix on the hosts.

Currently I only get only one ADVERTISE message though, so perhaps
they're working on improving this as we speak.

BTW, I found draft-ietf-dhc-dhcpv6-redundancy-consider-02, very useful
work that I'll pass along to my provider, thanks!

Best regards,
--
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

volz at cisco

May 19, 2012, 4:46 AM

Post #12 of 18 (934 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

In the pcap files you provided there was no server preference option ... Configuring that can help as the client should always prefer the same server (except if it is down when Solicit received).

That file also only showed IA_NA request; no IA_PD.

Sent from my iPad

On May 19, 2012, at 5:57 AM, "Tore Anderson" <tore.anderson [at] redpill-linpro> wrote:

> Hi,
>
> * John Jason Brzozowski
>
>> Tore your CMTS could be dropping the CONFIRM message. I know of only >
> one CMTS that drops this type of message. The Cisco 10K.
>
> The CMTS has a Cisco MAC address, so it seems likely that this is the
> reason why it doesn't work. Thanks - I'll discuss this with my provider.
>
>> The operator probably has two separate DHCPv6 servers running for
>> redundancy. As such, and in the absence of DHCPv6 failover support,
>> both servers will send an ADVERTISE. Does one server have a higher
>> preference value than the other?
>
> No preference values are being transmitted in the ADVERTISE messages.
> Hmm. I've had my PD prefix change on me once already, and that's the
> probably the reason. Unlike my laptop, my HGW (a ZyXEL P2812) sends
> RELEASE once its WAN port goes down, and starts the DHCPv6 client state
> machine from scratch (with SOLICIT) once it comes back up. So I guess
> that would mean it's a coin's toss whether I get back the same prefix I
> had before, or if I get the prefix offered by the other DHCPv6 server.
> Which is rather problematic, as the ZyXEL doesn't handle LAN renumbering
> very well, so I get left with stale and non-working addresses from the
> old prefix on the hosts.
>
> Currently I only get only one ADVERTISE message though, so perhaps
> they're working on improving this as we speak.
>
> BTW, I found draft-ietf-dhc-dhcpv6-redundancy-consider-02, very useful
> work that I'll pass along to my provider, thanks!
>
> Best regards,
> --
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com/

jjmbcom at gmail

May 19, 2012, 7:06 AM

Post #13 of 18 (937 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

On Sat, May 19, 2012 at 5:57 AM, Tore Anderson <
tore.anderson [at] redpill-linpro> wrote:

> Hi,
>
> * John Jason Brzozowski
>
> > Tore your CMTS could be dropping the CONFIRM message. I know of only >
> one CMTS that drops this type of message. The Cisco 10K.
>
> The CMTS has a Cisco MAC address, so it seems likely that this is the
> reason why it doesn't work. Thanks - I'll discuss this with my provider.
>
[jjmb] there are some other things we should discuss offline, perhaps with
your provider that I imagine are of interest. contact me at work if you
wish to discuss.

>
> > The operator probably has two separate DHCPv6 servers running for
> > redundancy. As such, and in the absence of DHCPv6 failover support,
> > both servers will send an ADVERTISE. Does one server have a higher
> > preference value than the other?
>
> No preference values are being transmitted in the ADVERTISE messages.
> Hmm. I've had my PD prefix change on me once already, and that's the
> probably the reason. Unlike my laptop, my HGW (a ZyXEL P2812) sends
> RELEASE once its WAN port goes down, and starts the DHCPv6 client state
> machine from scratch (with SOLICIT) once it comes back up. So I guess
> that would mean it's a coin's toss whether I get back the same prefix I
> had before, or if I get the prefix offered by the other DHCPv6 server.
> Which is rather problematic, as the ZyXEL doesn't handle LAN renumbering
> very well, so I get left with stale and non-working addresses from the
> old prefix on the hosts.
>
[jjmb] you should get your PD renewed, your operator may have to tweak some
CNR settings. CNR has great support for IPv6. I worked with that team
(include Bernie) over 6 years ago to help put it there.

>
> Currently I only get only one ADVERTISE message though, so perhaps
> they're working on improving this as we speak.
>
[jjmb] perhaps or they have a separate, single server for IPv6.

>
> BTW, I found draft-ietf-dhc-dhcpv6-redundancy-consider-02, very useful
> work that I'll pass along to my provider, thanks!
>
[jjmb] yup that is what they should use, I do.

>
> Best regards,
> --
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com/
>

--
===================================
John Jason Brzozowski
===================================

john_brzozowski at cable

May 19, 2012, 7:09 AM

Post #14 of 18 (935 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

By the way who runs this list?

How do I get my work email address added?

On Fri, May 18, 2012 at 4:03 AM, Tore Anderson <
tore.anderson [at] redpill-linpro> wrote:

> My cable provider just got included me in their IPv6 pilot. One of the
> first things I noticed when testing (using a computer directly attached
> to the cable modem) was that DHCPv6 Confirm messages went unanswered.
> The first time I connected went fast, while all subsequent connections
> (e.g. after resuming from suspend) was slow, as the Confirm request had
> to time out before information from the cached lease was used.
>
> I understood from my provider that the likely cause was that their Cisco
> CNR DHCPv6 server did not support DHCPv6 Confirm, and they also pointed
> me to the following UNH-IOL document, which says ŤTransmission of DHCPv6
> Confirm message is not expected on a DOCSIS WAN networkť:
>
>
> https://www.iol.unh.edu/services/testing/ipv6/grouptest/white_papers/CPE_IPv6_Test_Event_Whitepaper.pdf
>
> This strikes me as rather strange - as far as I can tell, the DHCPv6
> client has no way of determining if the Ethernet interface is running on
> is connected to a DOCSIS modem or something else, so I don't see how it
> could possibly selectively disable the use of Confirm in the case of
> DOCSIS.
>
> Does anyone have more information on why DHCPv6 Confirm wouldn't be
> expected and supported in DOCSIS networks? (Does it work in Comcast's
> network?)
>
> --
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com
>

bzeeb-lists at lists

May 19, 2012, 7:17 AM

Post #15 of 18 (935 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

On 19. May 2012, at 14:09 , John Jason Brzozowski wrote:

> By the way who runs this list?

dr does, but if you check the headers, they do have the RFC compliant List-*
headers that tell you all you need to know.

--
Bjoern A. Zeeb You have to have visions!
It does not matter how good you are. It matters what good you do!

tore.anderson at redpill-linpro

May 19, 2012, 7:59 AM

Post #16 of 18 (939 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

* John Jason Brzozowski

> [jjmb] there are some other things we should discuss offline, perhaps
> with your provider that I imagine are of interest. contact me at work
> if you wish to discuss.

I'll certainly take you up on this offer, thanks! My contact in Get (my
provider) is busy with non-IPv6 stuff in the next week though.

> No preference values are being transmitted in the ADVERTISE messages.
> Hmm. I've had my PD prefix change on me once already, and that's the
> probably the reason. Unlike my laptop, my HGW (a ZyXEL P2812) sends
> RELEASE once its WAN port goes down, and starts the DHCPv6 client state
> machine from scratch (with SOLICIT) once it comes back up. So I guess
> that would mean it's a coin's toss whether I get back the same prefix I
> had before, or if I get the prefix offered by the other DHCPv6 server.
> Which is rather problematic, as the ZyXEL doesn't handle LAN renumbering
> very well, so I get left with stale and non-working addresses from the
> old prefix on the hosts.
>
> [jjmb] you should get your PD renewed, your operator may have to tweak
> some CNR settings. CNR has great support for IPv6. I worked with that
> team (include Bernie) over 6 years ago to help put it there.

The problem is that my HGW will immediately forget all about the PD as
soon as you unplug the WAN port. I would imagine that this runs counter
to various RFCs, but that's how it behaves. So when I reconnect it to
the cable modem, it won't try to renew/confirm any previously received
IA_PD (or IA_NA for that matter), it starts the DHCPv6 client completely
from scratch. So if there's two DHCPv6 servers, offering two different
IAs, the chance of getting back my old prefix would be fifty-fifty,
right? (Assuming the Preference option isn't included in the ADVERTISE
messages, that is.)

> Currently I only get only one ADVERTISE message though, so perhaps
> they're working on improving this as we speak.
>
> [jjmb] perhaps or they have a separate, single server for IPv6.

They had two servers a couple of days ago, but now I see only one. So
perhaps they shut down one in order to implement the Preference option.
Or one crashed. No idea really. It's still at a early pilot stage so I
can imagine they feel free to change stuff around without notifying me. :-)

You can [un]subscribe from this list here:
http://lists.cluenet.de/mailman/listinfo/ipv6-ops

BR,
--
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

jjmbcom at gmail

May 19, 2012, 2:26 PM

Post #17 of 18 (940 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

On Sat, May 19, 2012 at 10:59 AM, Tore Anderson <
tore.anderson [at] redpill-linpro> wrote:

> * John Jason Brzozowski
>
> > [jjmb] there are some other things we should discuss offline, perhaps
> > with your provider that I imagine are of interest. contact me at work
> > if you wish to discuss.
>
> I'll certainly take you up on this offer, thanks! My contact in Get (my
> provider) is busy with non-IPv6 stuff in the next week though.
>
[jjmb] anytime.

>
> > No preference values are being transmitted in the ADVERTISE messages.
> > Hmm. I've had my PD prefix change on me once already, and that's the
> > probably the reason. Unlike my laptop, my HGW (a ZyXEL P2812) sends
> > RELEASE once its WAN port goes down, and starts the DHCPv6 client
> state
> > machine from scratch (with SOLICIT) once it comes back up. So I guess
> > that would mean it's a coin's toss whether I get back the same
> prefix I
> > had before, or if I get the prefix offered by the other DHCPv6
> server.
> > Which is rather problematic, as the ZyXEL doesn't handle LAN
> renumbering
> > very well, so I get left with stale and non-working addresses from
> the
> > old prefix on the hosts.
> >
> > [jjmb] you should get your PD renewed, your operator may have to tweak
> > some CNR settings. CNR has great support for IPv6. I worked with that
> > team (include Bernie) over 6 years ago to help put it there.
>
> The problem is that my HGW will immediately forget all about the PD as
> soon as you unplug the WAN port. I would imagine that this runs counter
> to various RFCs, but that's how it behaves. So when I reconnect it to
> the cable modem, it won't try to renew/confirm any previously received
> IA_PD (or IA_NA for that matter), it starts the DHCPv6 client completely
> from scratch. So if there's two DHCPv6 servers, offering two different
> IAs, the chance of getting back my old prefix would be fifty-fifty,
> right? (Assuming the Preference option isn't included in the ADVERTISE
> messages, that is.)
>
[jjmb] time for a new router, try dlink. ;)

>
> > Currently I only get only one ADVERTISE message though, so perhaps
> > they're working on improving this as we speak.
> >
> > [jjmb] perhaps or they have a separate, single server for IPv6.
>
> They had two servers a couple of days ago, but now I see only one. So
> perhaps they shut down one in order to implement the Preference option.
> Or one crashed. No idea really. It's still at a early pilot stage so I
> can imagine they feel free to change stuff around without notifying me. :-)
>
[jjmb] have them contact me off list, I can give them some guidance.

>
> You can [un]subscribe from this list here:
> http://lists.cluenet.de/mailman/listinfo/ipv6-ops
>
> BR,
> --
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com/
>

--
===================================
John Jason Brzozowski
===================================

mark at townsley

May 19, 2012, 11:33 PM

Post #18 of 18 (926 views)
Permalink

Re: DHCPv6 Confirm in DOCSIS networks [In reply to]

On May 19, 2012, at 2:36 AM, John Jason Brzozowski wrote:

> Tore your CMTS could be dropping the CONFIRM message. I know of only one CMTS that drops this type of message. The Cisco 10K.

Fixed in CSCtx01420

- Mark

>
> On Friday, May 18, 2012, Erik Kline <ek [at] google> wrote:
> >> It's sent to the ff02::1:2 multicast address. I'm using ISC dhclient
> >> version 4.2.3-8.P2, the standard one included in Fedora 16. You can see
> >> the two connections in the PCAP @ http://fud.no/get-init.pcap. Frames
> >> 1-7 is the initial connection with no cached lease, 8-13 is after
> >> reseating the Ethernet cable betwen my laptop and the modem. I don't see
> >> anything wrong with the exchange, but maybe you have better eyes...
> >
> > Please pardon my ignorance, but what's that second AdvertiseXID in
> > there? It has a different server identifier and assigns a different
> > address. The Confirms all seem to be for the address in the first
> > AdvertiseXID, not the 2nd.
> >
> > Is this normal?
> >
>
> --
> ===================================
> John Jason Brzozowski
> ===================================

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads