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
Beebee (wbeebee); erik.nordm...@sun.com
Cc: ipv6@ietf.org
Subject: comments on draft-ietf-6man-ipv6-subnet-model-03
Upon request from the author, I've reviewed the I-D, and here are my comments.
I have one top level comment: I'm okay with removing the following two bullets
from the original on-link
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,
I listened to the 6man WG on- and off-link presentation and responses
from the audio feed.
I have a comment relating to what Tony Hain said during the
presentation.
Inappropriately sending data to the default router is not catastrophic,
the data will be
forwarded by the router to the
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:
Here's my review of the DNA I-D:
One global concern:
I'm concerned that DNA may not be applicable to all networks. There
seems to be some
implicit assumptions about the networks that must be true - and these
assumptions are
not necessarily going to be true on all of the networks that DNA seems
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
As Bernie said, having two ways of doing the same thing, for example
having
both the RA and DHCPv6 determine the default gateway or on-link
information,
leads to both confusion and conflicts. Which one do you believe? If
you're
talking about security, both RA's and DHCPv6 can be spoofed - so
Section 3.1 of RFC 2461 describes intended behavior when a host
receives an RA without an advertised prefix:
Multiple prefixes can be associated with the same link. By
default, hosts learn all on-link prefixes from Router
Advertisements. However, routers may be configured to
26 matches
Mail list logo
