2013-02-06 00:45, Doug Barton do...@dougbarton.us :
On 02/05/2013 05:57 AM, Rémi Després wrote:
Hi, Doug,
Please see inline.
2013-02-04 à 18:37, Doug Barton do...@dougbarton.us :
On 02/04/2013 12:38 AM, Rémi Després wrote:
It remains that IIDs having u=1 SHOULD be unique, i.e.
Hi,
I was asked off list to clarify if the MAC addresses in the following list had
the Locally Assigned bit switched off, i.e. don't have 0x02 in their first
octet.
I've flagged the supposed globally unique ones below with a *. I've also
flagged the same OUI /vendor with a or + symbol when
Bob,
This is, in my understanding, what should be avoided in 6man, a debate on new
4rd modifications:
- The 4rd design has been stabilized for long in Softwire.
- The question to 6man is ONLY whether the proposed reserved range is
compatible with the IPv6 addressing architecture.
Thanks,
RD
Remi,
the point I'm trying to make is that the future of 4rd does not depend on 6man
accepting the request for a reserved space.
4rd can function very well without it.
cheers,
Ole
This is, in my understanding, what should be avoided in 6man, a debate on
new 4rd modifications:
- The 4rd
Dear Rémi,
Am 06.02.2013 11:13, schrieb Rémi Després:
This is, in my understanding, what should be avoided in 6man, a debate on
new 4rd modifications:
- The 4rd design has been stabilized for long in Softwire.
- The question to 6man is ONLY whether the proposed reserved range is
2013-02-06 à 13:07, Bless, Roland (TM) roland.bl...@kit.edu :
Dear Rémi,
Am 06.02.2013 11:13, schrieb Rémi Després:
This is, in my understanding, what should be avoided in 6man, a debate on
new 4rd modifications:
- The 4rd design has been stabilized for long in Softwire.
- The question
On 02/06/2013 10:52 AM, Rémi Després wrote:
- The reserved range is a tool to AVOID conflicts. It isn't, like DAD, a tool
to RESOLVE them when they occur.
DAD *detects* them, but does not resolve them (for instance, the last
D stands for detection). As a datapoint, all the v6 implementations
Le 2013-02-06 à 17:16, Fernando Gont ferna...@gont.com.ar a écrit :
On 02/06/2013 10:52 AM, Rémi Després wrote:
- The reserved range is a tool to AVOID conflicts. It isn't, like DAD, a
tool to RESOLVE them when they occur.
DAD *detects* them, but does not resolve them (for instance,
Hi,
Am 06.02.2013 14:52, schrieb Rémi Després:
As already said, the 4rd range only makes a first use of an existing
RFC4291 provision: The use of the universal/local bit in the
Modified EUI-64 format identifier is to allow development of future
technology that can take advantage of interface
RFC4291 is clear that packets destined to ff01::/16 must never leave
the local node, but what should be done if such packets are received
as a result from a broken implementation on the other side?
//E
IETF IPv6 working group
Hi Fernando,
Am 06.02.2013 17:16, schrieb Fernando Gont:
On 02/06/2013 10:52 AM, Rémi Després wrote:
- The reserved range is a tool to AVOID conflicts. It isn't, like DAD, a
tool to RESOLVE them when they occur.
DAD *detects* them, but does not resolve them (for instance, the last
D
2013-02-06 17:41, Bless, Roland (TM) roland.bl...@kit.edu :
Hi,
Am 06.02.2013 14:52, schrieb Rémi Després:
As already said, the 4rd range only makes a first use of an existing
RFC4291 provision: The use of the universal/local bit in the
Modified EUI-64 format identifier is to allow
Hi,
On 06.02.2013 17:20, Erik Hugne wrote:
RFC4291 is clear that packets destined to ff01::/16 must never leave
the local node, but what should be done if such packets are received
as a result from a broken implementation on the other side?
Be liberal in what you accept, and conservative in
Hey Ole,
Cisco has this implemented in certain code trains today (on nexus/6500
platforms), and there is at least one other switch manufacturer that is
about to release it as well.
Thanks,
-igor
On Tue, 5 Feb 2013, Ole Troan wrote:
:: Erik, Igor,
::
:: as part of doing the writeup to the
TM == TM Bless writes:
RFC4291 is clear that packets destined to ff01::/16 must never
leave the local node, but what should be done if such packets are
received as a result from a broken implementation on the other
side?
TM Be liberal in what you accept, and
Hi Fernando,
If the chairs were to initiate a last call, I would support this document.
Maybe the chairs can comment?
Ron
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
Fernando Gont
Sent: Monday, February
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Michael,
On 06.02.2013 19:23, Michael Richardson wrote:
TM == TM Bless writes:
RFC4291 is clear that packets destined to ff01::/16 must never
leave the local node, but what should be done if such packets
are received as a result from a
Hi,
On 06.02.2013 17:55, Rémi Després wrote:
Am 06.02.2013 14:52, schrieb Rémi Després:
As already said, the 4rd range only makes a first use of an existing
RFC4291 provision: The use of the universal/local bit in the
Modified EUI-64 format identifier is to allow development of future
Ron,
thanks for the reminder.
If the chairs were to initiate a last call, I would support this document.
Maybe the chairs can comment?
Bob and I will discuss progress on this document in our call next week.
Best regards,
Ole
while we are on the topic, and you made me re-read the document.
section 4:
issues with terminology. call a device that walks the extension header chain
something else than a router.
rfc2460 definition of a router; extension headers are not examined or
processed by any node along a packet's
Ole,
I am supporting this draft because the community has become accustomed to
stateless firewalls on routers. These stateless firewalls are capable of
filtering based upon information gleaned from both the IPv6 and L4 header.
When a stateless firewall encounters an IPv6 datagram in which the
On 2/6/13 3:41 PM, Ronald Bonica wrote:
Ole,
I am supporting this draft because the community has become accustomed to
stateless firewalls on routers. These stateless firewalls are capable of
filtering based upon information gleaned from both the IPv6 and L4 header.
When a stateless firewall
On 02/06/2013 06:51 PM, Ole Troan wrote:
while we are on the topic, and you made me re-read the document.
section 4: issues with terminology. call a device that walks the
extension header chain something else than a router. rfc2460
definition of a router; extension headers are not examined
23 matches
Mail list logo
