What happens when both RA and DHCPv6 are configured?
- Wes
On 10/28/11 9:11 AM, Brian Haberman br...@innovationslab.net wrote:
All,
The MIF WG is currently defining a DHCPv6 option for defining
routes (including default routes) on client nodes. Please review the
draft and provide any
Erik,
I have seen NUD packets dropped during congestion, and for traffic to
periodically drop out for re-resolution. I agree with the goal of making
NUD more robust. However, there may be other approaches besides
retransmitting more times.
- Wes
On 5/23/11 2:46 PM, Erik Nordmark
New:
t DHCPv6 xref target='RFC3315' / can be used to obtain and
configure addresses. In general, a network may provide for the
configuration of addresses through Router Advertisements,
DHCPv6 or both. Some operators have indicated that they do
not intend
I do not believe there needs to be special wording for mobile
Or for any other specific deployment for that matter. The reason I
mentioned cable is because many popular operating system-based hosts as well
as specific devices have to be able to operate in a cable environment and
the
Hemant and I discussed this draft. Why doesn't the RG send an NS(DAD) for
the LLA out to the Edge Router and have the Edge Router set up a tunnel with
the RG. Then, the RA can be tunnelled using the unicast LLA to the RG and
decapsulated at the RG. This would avoid having the Edge Router to
One of the problems I have with this draft is that I don¹t think all of the
hardware platforms necessarily will support it in hardware. Saying, ³oh
well, it¹s a layer violation², is not good enough we routinely look at the
ethertype (in the L2 header) of the packet and match it up with the L3
As this draft is changing what has been a fundamental and fixed
assumption for a very long time (i.e. layer 3 multicast always equals
layer 2 multicast), I think it's important that use cases supporting it
are very clear in what they're trying to achieve and why allowing
multicast layer 3
In case people haven¹t had time to read the whole draft, the key standards
track change to existing RFC¹s is:
³An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast
message containing a multicast destination address in the IPv6
header, but with a unicast destination address in the
I support this effort as I think it will future proof extension
headers as far as stateful firewalls are concerned - but what I'm
interested in is finding out how much demand for new extension headers
there is out there - and what those new extension headers would be.
- Wes
-Original
You can use unrelated addresses at each end if you use RA w/PIO's to
inject on-link prefixes in the Prefix Lists on both routers.
Thanks,
- Wes
Wes Beebee
Software Engineer
Product Development
wbee...@cisco.com
United States
Cisco.com - http://www.cisco.com
For corporate legal information go
The problem is - without something like this, it's impossible to ever
expire a prefix or make sure that something is, indeed, off-link.
- Wes
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Christian Huitema
Sent: Thursday, December 24, 2009
I think the simplest solution to (2) is, frankly, to open connections
at some
rate (if I have N addresses and my peer has M, send a SYN-or- whatever
on
successive pairs in the cross-product every K milliseconds until I get
a SYN-ACK
on one of them, and then close all other sessions).
+1
I
Regarding Note that Redirect Messages can also indicate an address is
off-link.
I think we've removed that from the latest draft, which is available at
http://www.ietf.org/id/draft-ietf-6man-ipv6-subnet-model-05.txt
We have instead, the text (in section 2.2):
Note that Redirect Messages do not
One common way of setting up a residential gateway is to first set up a
PC connected to the ISP, let it get an IPv4 address through DHCPv4, tell
the ISP about it and get the MAC address and DHCPv4 lease recorded (and
reserved) in the ISP servers (to get it online). Then, the customer
hangs up the
Supported.
Thanks!
Two comments, however.
1. An Updates: 4861 header is required
Agreed!
2. Why does it contain the pre-5378 disclaimer (This document may
contain material...)?
If the only issue is that material conributed by Thomas Narten is
included, Thomas could give
us the OK to
in the working group
to help determine the consensus of the working group?
Thanks,
Wes
-Original Message-
From: JINMEI Tatuya / 神明達哉 [mailto:jinmei_tat...@isc.org]
Sent: Thursday, May 07, 2009 2:53 PM
To: Thomas Narten
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee); erik.nordm...@sun.com
See comments in-line below:
-Original Message-
From: Thomas Narten [mailto:nar...@us.ibm.com]
Sent: Wednesday, May 06, 2009 1:28 PM
To: JINMEI Tatuya / 神明達哉
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee); erik.nordm...@sun.com;
ipv6@ietf.org
Subject: Re: comments on draft-ietf-6man
It's of course unicast (note the to P::X). BTW I don't understand this
part: the L2 link-layer address of Y is available to X when X receives the
unicast NUD message. Why is this ensured? For example, X may have just
been rebooted and its neighbor cache may be empty.
That's because the
traffic from a
source that is not deemed on-link by the node whereas #3 discourages such
traffic.
- Wes
-Original Message-
From: JINMEI Tatuya / 神明達哉 [mailto:jinmei_tat...@isc.org]
Sent: Tuesday, May 05, 2009 12:34 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); erik.nordm
Jinmei,
I have fixed the sections numbers in the email reply below and responded to
your comments. Please see in line below.
- Wes
-Original Message-
From: JINMEI Tatuya / 神明達哉 [mailto:jinmei_tat...@isc.org]
Sent: Wednesday, April 29, 2009 8:10 PM
To: Hemant Singh (shemant); Wes
The failure model in the absense of the link's router(s) are described
in RFC 4943.
In particular, the assumption that all hosts are on-link in the absence
of RA's was deprecated.
Whether there is something more useful that can be done in this case is
future work that the IETF may or may not
on this and close on
this issue.
Thanks,
- Wes
_
From: Hemant Singh (shemant)
Sent: Friday, July 18, 2008 11:20 AM
To: '[EMAIL PROTECTED]'; Wes Beebee (wbeebee)
Cc: Suresh Krishnan; Thomas Narten; Brian Haberman; Bob Hinden;
ipv6@ietf.org
Subject
Sorry to reopen this, but do you think that the following clarification
could be added to the IPv6 Subnet Models draft to address bullets three
and four of the on-link definition in the Terminology section of RFC
4861:
Since only the Neighbor Cache is updated with the source address of a
received
propose this
same solution in our new text (last paragraph of section 2) that Hemant just
sent out.
- Wes
-Original Message-
From: JINMEI Tatuya / 神明達哉 [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 10, 2008 3:54 PM
To: Hemant Singh (shemant)
Cc: Suresh Krishnan; Wes Beebee (wbeebee); Thomas
Tatuya,
Please see in line below between wb and /wb
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2008 9:50 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); Thomas Narten; Brian Haberman; Bob Hinden;
ipv6@ietf.org
Subject: Re: 6MAN
Comments from me between wb and /wb
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Hemant Singh (shemant)
Sent: Thursday, July 03, 2008 4:36 PM
To: Thomas Narten; Brian Haberman
Cc: ipv6@ietf.org; Bob Hinden
Subject: RE: 6MAN WG Last
This rule derives directly from the Terminology section of RFC 4861
(definition of on-link).
Note that the presence of a bogus entry causes no harm (the routing
table takes precedence
over the ND cache in this case).
However, the removal of the rule DOES cause harm in the case of
communication
Section 1
=
Sure - no problem.
Section 2 Steps 1-4
===
These steps are absolutely necessary. They derive from RFC2461, but are
spread throughout and implied by the RFC. Our goal is not to add new
requirements in this draft. Our goal is simply to reiterate, in one
place,
.
This is quite unfortunate, since now we have to be extremely careful to
understand EXACTLY when
a destination is on- or off-link. On-link determination is no longer
just a performance optimization,
it's a basic data forwarding correctness issue.
- Wes Beebee
If we're now going to make major changes to the core of IPv6 and combine
ND and
DHCP at this late hour, then it would probably be a good idea to involve
all the
stakeholders in this decision - so I'm widening the audience to the IPv6
ND team
for comment.
- Wes
-Original Message-
From:
]
Subject: RE: [Fwd: WGLC for draft-ietf-dna-protocol-06.txt]
Suresh,
I have few minor comments on this I-D. Wes Beebee will send more
detailed comments sometime later today. He has reviewed the I-D.
1. While reading the Abstract, I'd like to know what is the maximum
delay DNAv6 is ready
DHCPv6 is useful when MSO's want to control which CPE's get addresses and which
do not. It provides a simple way to do access control on a network. Could a
hacked-up rogue system still manage to get on? Probably - but at least it bars
casual users from getting on a network that they're not
to us by the total network upgrade to IPv6 in order to designing a
better
system than IPv4.
- Wes Beebee
-Original Message-
From: Ralph Droms (rdroms)
Sent: Saturday, August 11, 2007 6:29 AM
To: Leino, Tammy
Cc: ipv6@ietf.org; John Jason Brzozowski (JJMB)
Subject: Re: prefix length
this
and failure to do so can result in lack of interoperability and
connectivity.
- Wes Beebee
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
34 matches
Mail list logo
