Hi Brian,
On 09.10.2013 01:10, Brian E Carpenter wrote:
I don't care about NAT66 but if you mean NPTv6, I suppose it's true.
Inserting may or perhaps might is OK by me.
You are right, I meant NPTv6 - sorry didn't use the correct term.
Regards,
Roland
Hi,
On 31.05.2013 11:46, Ray Hunter wrote:
But why are people coming up with these schemes for encoding semantics
in the address prefixes in the first place? That's what I'd like to
understand first and foremost: what lack of functionality is
motivating/forcing these people to adopt such
Hi Ole,
Am 29.05.2013 13:47, schrieb Ole Troan:
confused. a host cannot support IPv6 if it doesn't support ND. could
you please clarify?
I'm not sure that your statement is fully correct.
Though I'm convinced that ND provides many useful
features, in specific environments and rare cases
the
Hi Ole,
Am 29.05.2013 14:49, schrieb Ole Troan:
confused. a host cannot support IPv6 if it doesn't support ND. could
you please clarify?
I'm not sure that your statement is fully correct.
Though I'm convinced that ND provides many useful
features, in specific environments and rare cases
Hi Brian,
Am 29.05.2013 15:00, schrieb Brian Haberman:
On 5/29/13 8:46 AM, Bless, Roland (TM) wrote:
I'm not sure that your statement is fully correct.
Though I'm convinced that ND provides many useful
features, in specific environments and rare cases
the use of ND may be problematic (due
Hi Brian,
I was referring to RFC 2460. RFC 6434 states
ND SHOULD be supported, which makes perfectly sense.
In very rare cases you may not be able to use ND
(e.g., if you have a unidirectional medium etc.).
But there are MUSTs sprinkled in that section as well...
The way I read it was:
Hi Randy,
On 20.02.2013 12:40, Randy Bush wrote:
Yes, I know in practice they do leak, that's why I wrote should. My
statement was a little bit imprecise - I apologize. No leakage wasn't
actually my point rather than internal use only. So no matter which
kind of addresses you employ for
Hi,
After reading the email thread on draft-carpenter-6man-ug-00.txt,
the 6man chairs think the sense of the work group is:
1) The u and g bits did not end up being as useful as was thought when
RFC4291 was standardized. Consequently, we don't think there is any need to
continue the
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
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
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
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
Hi all,
On 05.02.2013 16:51, Rémi Després wrote:
Several opinions against a 4rd-range reservation have also been
expressed, but they concern the purpose of 4rd, or its experimental
status, or personal feelings against one more specification. They are
not about technical compatibility with the
Hi Rémi,
On 20.12.2012 09:54, Rémi Després wrote:
Interface addresses at the link layer are specified by IEEE to be
universally unique. This has been effective fort link-layer
communication to need neither manual configuration nor a DAD-like
protocol at this layer.
IEEE link layer addresses
Hi,
it's not really clear to me what (particular) problem we are trying to
solve here. I don't think that it's a good idea to introduce a structure
into the IID. The IID space is usually flat and the u- and g-bit
semantics are only relevant in the IEEE EUI format. It's clear
that we map them
Hi,
On 19.12.2012 14:21, Rémi Després wrote:
Could we limit the 6man discussion to the question asked by Softwire,
i.e. whether new IID types can be defined, using u=g=1, with a first
Sorry, I'm not yet aware of a concept called IID _types_?
Do we really have such a
On 19.12.2012 16:58, Brian E Carpenter wrote:
Do we really have such a thing IID types?
I think that's an important point. If we could make a statement like
The IID consists of N bits that have no meaning; the only constraint
is that they must be unique within the scope of a given link and
Hi Rémi,
On 19.12.2012 18:59, Rémi Després wrote:
As is, the sentence misses that IIDs that have u=1 are expected to be
universally unique. (This uniqueness is key to ensure that, as long
I don't agree. From an IPv6 functional point of view, IIDs only need to
be unique within the
18 matches
Mail list logo
