The
address%scope_type.id_in_the_scope
just does not feel right to me. I don't like notations which allow
writing erroneous expressions, whenever it can be avoided. And, I'm
not yet quite convinced, that this case needs such error-allowing
notation.
Thus I prefer
Steve Deering wrote:
At 12:29 PM +0900 3/21/02, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
wrote:
Perhaps we have two choices:
1. treat :: as global
2. does (explicitly) not define the scope type (level) of ::
Even the choice 2 will make the document clear, and it will
Thus I prefer
address%id_in_the_scope
and scope type is from address.
I also prefer this notation. It removes any ambiguity about
what a node is supposed to do if the address and the scope
number don't match.
And, then make sure every address has
a definite scope designated (the
Glenn Morrow wrote:
In which case, I violently agree with Keith. We've already
overloaded IP addresses with two functions - locator and
identifier.
I would rather see the WG focus on the value of using a bit to specify
whether the address is intended to be both a locator and
On Thu, 21 Mar 2002, Pekka Nikander wrote:
Unfortunately, this method is encumbered by IPR claims from Microsoft
and Ericsson, and therefore it received violent opposition at the
mobile-ip working group. As a result, the MIPv6 Design Team resolved
to the more modest proposal of just
Erik,
As I recall we didn't define the U/L bit ; the IEEE did, and we decided
to invert it. And I thought the U/L bit was only part of the ID allocation
mechanism more than anything else. It has an unfortunate side effect of
appearing to add semantics to the identifier field, but I don't think
As I recall we didn't define the U/L bit ; the IEEE did, and we decided
to invert it. And I thought the U/L bit was only part of the ID allocation
mechanism more than anything else. It has an unfortunate side effect of
appearing to add semantics to the identifier field, but I don't think it
We would like to announce that Margaret Wasserman is becoming a co-chair of
the IPv6 working group. This is effective now. Margaret has been involved
in the IPv6 (aka IPng) working group since close to the beginning and will
add valuable cycles to running and managing the working group.
We
Pekka Savola wrote:
We MUST NOT reserve bits in the address to support IPR'd mechanisms.
Actually, the intention is just the reverse. The intention is to
reserve a bit (or bit pattern) so that the IPR'd mechanims NEED NOT
to be used for future better security protocols. CGA can be used
On Thu, 21 Mar 2002, Pekka Nikander wrote:
Pekka Savola wrote:
We MUST NOT reserve bits in the address to support IPR'd mechanisms.
Actually, the intention is just the reverse. The intention is to
reserve a bit (or bit pattern) so that the IPR'd mechanims NEED NOT
to be used for future
Pekka Savola wrote:
We MUST NOT reserve bits in the address to support IPR'd mechanisms.
That wasn't the case. The proposal is:
1) Allocate the bit
2) Use the bit value 0 to signify default parameters for ANY use (not just MIP)
3) Reserve the bit value 1 for future purposes
There's two
Hi Francis,
From: Francis Dupont [EMAIL PROTECTED]
If the MN moves from the site A to site B, the MN cannot determine the
direction to which it should send a packet destinated to
fec0:0:0:100:1234:5678:9abc:def0. The destination address can be both
on the site A and the site B.
Our assumptions are different: you assume CGA is used (except when
signalled not to), I assume CGA will not be used (unless signalled to do
so).
In the latter case, I'm not sure if bits are necessary.
The bidding down issue has been discussed on the mobile IP mailing list
and so far nobody
Erik Nordmark wrote:
...
we point out [somewhere]
that e.g. future transport protocols might use the knowledge that
the interface ID is globally unique when the U bit is set
I seem to recall some discussion that this was broken since the U
bit is not totally trustworthy - this relates of
Well, the original idea was to reserve a bit to indicate that the
address is Cryptographically Generaged Address (CGA), basically
meaning that
if the bit is set, then
interface id = low64(hash(PK, stuff)) mask
where
PK is a public key to be used as an
Title: RE: New WG flow label draft (-01)
However, I still think the MUST not be changed
statementmay limit its future potential. For instance what if the
signaling used explicitly indicated that the field could be changed or not
changed en-route. This seems to handle the case when
Hi all,
I unintentially left Marc Blanchet off of the Node Requirements team on my
presentation today.
This was a mistake, so I wanted to appologize to Marc let the WG know that he is
part of
the team.
John
IETF IPng
Keith Moore writes:
Well, the original idea was to reserve a bit to indicate that the
address is Cryptographically Generaged Address (CGA), basically
meaning that
if the bit is set, then
interface id = low64(hash(PK, stuff)) mask
where
PK is a public
Mohan Parthasarathy wrote:
Now, when bob receives the packet sent by Alice, he has no other knowledge
about Alice except the packet itself. In particular, the only information
he has about Alice is the source IP address in the packet.
I am missing something here. Isn't the packet carrying
Mohan Parthasarathy wrote:
t very clear as to why you have to reserve a bit in the
address to express different security mechanisms being used. Why can't
this be built into the protocol itself ? Is it because that the future
security mechanisms will not use the same set of message exchanges
I have three concerns about this CGA/KBA idea:
- first this idea is about interface IDs, not addresses (so for Mobile
IPv6 we need Return Routability too). Kempf's I-D about neighbor
discovery is about real addresses and ABK (address based keys) which
has not this and the last concerns.
Title: RE: Allocating a bit in the RFC2374 Interface Identifier
Mohan Parthasarathy wrote:
t very clear as to why you have to reserve a bit in the address to
express different security mechanisms being used. Why can't this be
built into the protocol itself ? Is it
As pointed out in the 6bone meeting today and on the ipv6mh list, there is a semantics
issue using the acronym TLA. Unless we have missed something, it does not exist
anymore.
1. We still need a word or acronym to describe the concept, even though it does not
aggregate at the /16 boundary.
2.
On Thu, 21 Mar 2002, Dave Thaler wrote:
For transition (and maybe other reasons), the receiving node wants to
also be able to communicate with nodes which do not do the above, and
hence needs to distinguish upon receipt of the packet in question
whether it should drop the packet because the
Just an idea:
If there is an entire class of problems that can only be solved by a flag
in the address itself, why not reserve the top 16 bits of the Interface
Identifier? To put it another way, if having semantically significant
bits in the address is the best solution for a problem or two
On Thu, 21 Mar 2002, Francis Dupont wrote:
- last I don't believe you can manage real trust with only one bit
and if you need more bits to negociate someting the IPv6 address
will become quickly too small. IMHO this is a dead-end.
100% agree.
And please apply some commercial
On Thu, 21 Mar 2002, Michel Py wrote:
As pointed out in the 6bone meeting today and on the ipv6mh list, there is a
semantics issue using the acronym TLA. Unless we have missed something, it does not
exist anymore.
1. We still need a word or acronym to describe the concept, even though it
Wow, now we are overloading the acronym TLA... I just got that today for
no good reason...
TLA: Old acronym that stands for Three Letter Acronym. Technical bodies
enjoy creating these objects in their standards
TLAng: Next Generation acronym that stands for Top Level Aggregator. See
TLA.
Francis Dupont wrote:
- second the verification implies an expensive crypto operation
(typically a signature check) so the scheme is subject to trival DoS
attack, especially if each packet has to be checked (so or a session
key is negociated with an even more expensive and complex
Mohan Parthasarathy wrote:
Note that the MitM can also change the IP address, but if he
does so, he is *not* attacking the original host, as the
address is changed.
Ok. This is not very obvious (at least to me). It would be useful
to put this in some document.
Is it possible
In your previous mail you wrote:
- second the verification implies an expensive crypto operation
(typically a signature check) so the scheme is subject to trival DoS
attack, especially if each packet has to be checked (so or a session
key is negociated with an even
Since a spoofer can construct any packet they like, and NOT include
any authentication data, a bit in the source address seems to be the
only way for a receiver who cares, to know whether to drop it (because
auth data is missing) or accept it (because it's a legacy insecure
address).
yes,
Note that the MitM can also change the IP address, but if he does
so, he is *not* attacking the original host, as the address is
changed.
unless of course the MitM can convince that host to take on that address
as an alias.
Kind of tricky for FireWire
Brian
John F. Leser wrote:
Just an idea:
If there is an entire class of problems that can only be solved by a flag
in the address itself, why not reserve the top 16 bits of the Interface
Identifier? To put it another way, if having semantically
On Thu, 21 Mar 2002 08:13:44 -0500,
Margaret Wasserman [EMAIL PROTECTED] said:
Thus I prefer
address%id_in_the_scope
and scope type is from address.
I also prefer this notation. It removes any ambiguity about
what a node is supposed to do if the address and the scope
number don't
In your previous mail you wrote:
Kind of tricky for FireWire
= Brian, do you suggest that FireWire (aka I-Link aka IEEE 1394) uses
64 bit addresses?
Regards
[EMAIL PROTECTED]
IETF IPng Working Group Mailing List
IPng
Pekka Savola wrote:
Or perhaps you should describe in detail what the term would
be useful for in this context?
There different things involved:
- Allocation policies, which is We give a /32 to Joe for this reason and a /35 to
Jane for that reason.
- Aggregation policies, which is All
Hi,
I wanted to add a few cents to the discussion, triggered by Francis saying
we're going nowhere :-)
- router renumbering hasn't been made to work yet, so I doubt that's a
good option
- pppext might be workable for PPP connections, and is a valid mechanism
especially if there is no simple
On Thu, 21 Mar 2002 10:54:25 +0200,
Markku Savela [EMAIL PROTECTED] said:
The
address%scope_type.id_in_the_scope
just does not feel right to me. I don't like notations which allow
writing erroneous expressions, whenever it can be avoided. And, I'm
not yet quite convinced, that
From: JINMEI Tatuya / 神明達哉 [EMAIL PROTECTED]
Then, does the following plan make sense?
- in the definition of zone indices (Section 6 in the 03 draft),
specify that a zone ID includes its scope type and an ID in the
scope when an implementation handles the zone IDs.
- in the
In your previous mail you wrote:
I wanted to add a few cents to the discussion, triggered by Francis saying
we're going nowhere :-)
= my comment was about the addressing architecture, for the prefix
delegation we have a promise of a requirement document.
- router renumbering
In your previous mail you wrote:
Although, I wonder, why is it a REQUIREMENT that system MUST encode
into format that that contains both type and zone id?
= oh god! Look for the discussion in the mailing-list archive and
please don't reopen it.
Regards
[EMAIL PROTECTED]
- router renumbering hasn't been made to work yet, so I doubt that's a
good option
I agree. Moreover, you can't use it when you assume a site-boundary between
a WAN port and LAN ports of CPE.
- pppext might be workable for PPP connections, and is a valid mechanism
especially if there is no
On Fri, 22 Mar 2002, Yamasaki Toshi wrote:
- pppext might be workable for PPP connections, and is a valid mechanism
especially if there is no simple alternative (e.g. if the only alternative
is full statefull DHCPv6).
No. PPPext solves the issue only when you use PPP. That means you need
On Fri, 22 Mar 2002, Pekka Savola wrote:
I don't think that anyone is assuming 100% automatic prefix generation
like EUI64 IID generation: rather, I assume that in (at least almost)
every case, the prefixes will be configured statically somewhere, along
the lines identifier/customer:
On Fri, 22 Mar 2002, Tim Chown wrote:
On Fri, 22 Mar 2002, Pekka Savola wrote:
I don't think that anyone is assuming 100% automatic prefix generation
like EUI64 IID generation: rather, I assume that in (at least almost)
every case, the prefixes will be configured statically somewhere,
Francis Dupont wrote:
In your previous mail you wrote:
Kind of tricky for FireWire
= Brian, do you suggest that FireWire (aka I-Link aka IEEE 1394) uses
64 bit addresses?
Now that would be a silly suggestion wouldn't it? I think I mistyped...
it's late in the week.
Brian
Brian,
Michel Py wrote:
The point I am trying to make here is that we need a name
or acronym for ISPs that receive their addresses directly
from a RIR. I am not saying that TLA is the best
definition, but it does fit, regardless of allocation
policies and aggregation policies.
Brian
48 matches
Mail list logo
