Subject: Next steps on Reserving bits in RFC 2473 Interface IDs?

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Mar 2002 09:55:33 +0100 (CET)

A while back I sent an email to the list talking about
Reserving bits in RFC 2473 Interface IDs.

Not much email has followed on this topic so it isn't clear whether
people are having too much fun debating other topics, think it is
a good/bad idea, or just don't care.

I think our choices are:
1. Do nothing
2. Reserve a quarter of the IID space i.e. universal=1, group=1 becomes
   explicitly reserved.
3. Reserve half of the IID space i.e. all addresses with group=1 become
   explicitly reserved.

It would be good to try to make progress on the mailing list on this question
otherwise it's likely to appear on the agenda in the meetings next week :-)

  Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Tue, 12 Mar 2002 11:20:06 +0200

> From: Erik Nordmark <[email-masked]>
> 

rfc-2373 I presume...

My opinion on this is: these ID related issues all belong to
IP-over-foo documents. The rfc-2373 should only talk about (prefix=n,
interface ID = 128-n), and not care at all what the ID bits are.

Thus, all references to EUI-64 should be removed from 2373.

I feel it would be cleaner specification that way, but if people want
to keep EUI-64 and other bits, I'm not going to nag you too much. Just
giving this "opinion" for the record.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 12 Mar 2002 10:21:53 +0100

Hello Erik,

I really think this is an important topic....
Considering the MobileIP mailing discussions it would make
sense to have an IID space reserved for "RR-addresses".
I also believe that an IID space should also be reserved for CGA
(Crypto. Generated ) addresses...
I would therefore vote for choice #3...

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Robert Elz <[email-masked]>
Date: Tue, 12 Mar 2002 17:11:44 +0700

Date:        Tue, 12 Mar 2002 11:20:06 +0200
    From:        Markku Savela <[email-masked]>
    Message-ID:  <[email-masked]>

  | My opinion on this is: these ID related issues all belong to
  | IP-over-foo documents. The rfc-2373 should only talk about (prefix=n,
  | interface ID = 128-n), and not care at all what the ID bits are.

I agree.

  | Thus, all references to EUI-64 should be removed from 2373.

Yes.  Exactly.

2373 should go no further than recommending that IPv6 over foo specs
should use no more than 64 bits as the interface ID.   The language
that does that can be strong - but no matter how strong it can never
be more than a recommendation, the authors of a later standard are always
free to override an older one (assuming they can get rough consensus, ...)

It needs to be made very very clear that no-one can ever take the low 64 bits
of an IPv6 address, and attempt to make any sense out of them at all.
The bits have meaning only within the scope of the prefix that assigns
them, and can be interpreted only by knowing the assignment rules of
whoever controls the prefix.

Common sense rules like "set (the inverted) u=1 when autoconfiguring"
make sense - they make it easy to mix & match assignment styles within
a prefix - but no-one other than the owner of the prefix in question
should be relying upon such a rule being applied.

kre

---

From: Alexandru Petrescu<[email-masked]>
Date: 12 Mar 2002 11:57:37 +0100

Robert Elz <[email-masked]> writes:
> should use no more than 64 bits as the interface ID.

I'm very curious if the suggested recommendation is really "no more
than 64" or is it "exactly 64"?

Alex

---

From: Alexandru Petrescu<[email-masked]>
Date: 12 Mar 2002 12:10:36 +0100

> 3. Reserve half of the IID space i.e. all addresses with group=1 become

Hi Erik, I have a side remark with respect to the u/g bits, and this
might be because of a not so solid understanding of why they're there.

Since u and g have approximately the same semantics that can be found
in the 8bit prefix of the addres I was believing that they're
necessary only for Ethernet-derived environments, where they can be
exploited by specific Ethernet optimizations for multicast, etc.

When other than Ethernet link layers are involved, probably the
functionality of the u/g bits can be derived from the 8bit prefix?
Maybe it's the 8bit prefix that should be tweaked to obtain the
reservations proposed?

Please take this as an aside only, I might be completely wrong of the
rationale behind the u/g.

Alex

---

From: Robert Elz <[email-masked]>
Date: Tue, 12 Mar 2002 20:26:15 +0700

Date:        12 Mar 2002 11:57:37 +0100
    From:        Alexandru Petrescu<[email-masked]>
    Message-ID:  <[email-masked]>

  | I'm very curious if the suggested recommendation is really "no more
  | than 64" or is it "exactly 64"?

It is currently probably exactly 64 - but there's no reason for that.

A link layer that doesn't have a use for all 64 bits shouldn't be
required to pad them for no reason (note: the "padding" done by the
ethernet layer isn't for no reason - it allows for the possible
bridging between IEEE nets that use EUI-48s and those that use EUI-64's,
and while that seems most likely very distasteful to me, so is bridging
FDDI to ethernet, and we know that's been done...)

The "no more than 64" is to make sure that standard sized address allocations
can work on all link layers.

kre

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Mar 2002 15:17:20 +0100 (CET)

> exploited by specific Ethernet optimizations for multicast, etc.

The universal bit is defined in 2373bis (addr-arch-v3) to
apply to most of the address space, thus it is not tied to the link-layer 
being Ethernet.
And IP-over-Ethernet spec doesn't do anything different as a function
of the IID when transmitting packets on the Ethernet.

> Maybe it's the 8bit prefix that should be tweaked to obtain the

Do you have a concrete proposal?

  Erik

---

From: Robert Elz <[email-masked]>
Date: Tue, 12 Mar 2002 22:10:27 +0700

Date:        Tue, 12 Mar 2002 15:17:20 +0100 (CET)
    From:        Erik Nordmark <[email-masked]>
    Message-ID:  <[email-masked]>

  | The universal bit is defined in 2373bis (addr-arch-v3) to
  | apply to most of the address space, thus it is not tied to the link-layer 
  | being Ethernet.

And should be deleted from there before that draft goes anywhere.

Pretending that a bit in the middle of the address can have any useful
function this way is simply foolish.

kre

---

From: Alexandru Petrescu<[email-masked]>
Date: 12 Mar 2002 17:12:14 +0100

Hi Erik, I'll pick the gauntlet, with great care :-)

> Do you have a concrete proposal?

You seem to imply that the u/g bits are there not because of Ethernet,
then I can observe that:

universal bit =1 has similar meaning to Prefix =001
group bit =1     has similar meaning to Prefix =1111 1111

Many other prefixes are unassigned and as such can serve the purpose
of about anything.  For example, Prefix 010 could mean randomly
generated Interface ID's.

When doing this, I think it would be good to extract the commonalities
of the usage scenarios of the current proposals, see how they fit the
current Prefixes and what are the additional criteria needed to
classify them.

For example, how can one classify a randomly generated Interface ID
and a Cryptographically Generated Address?  Random IID serves privacy.
CGA serves authentication of something.  Both are security, BUT random
IID also serves certain types of L2's, nothing to do with security.
Both are global unicast and are not group.

Since I find the classification difficult I think I'll refrain from
proposing anything serious.

What do you think?

Alex

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Mar 2002 09:00:10 -0800

Erik,

I might have missed this point, but let me ask the question just in case
it hasn't been asked.

One of the purposes of reserving this bit is to avoid "bidding down"
attacks in Mobile IPv6 binding update security, whereby an attacker
requests a less secure method so it can mount an attack. One issue that
comes to mind is that, by reducing the size of the address space, a
reserved bit essentially makes it easier for an attacker to randomly
seek through the address space for addresses that aren't protected by
the bit. I've not actually gone through an in-depth analysis of this, so
the statistics may still put such search in the category of a hard
problem, but nevertheless I think it needs some consideration (if it
hasn't already had some).

Has this been considered?

            jak

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Mar 2002 21:12:42 +0100 (CET)

> hasn't already had some).

Sorry, wrong topic.

The purpose of *reserving* the bit(s) is to leave the door open
to assign the bit(s) to something, hopefully useful, in the future.

It is true that a possible *use* of the bits in the future is avoiding
bidding down attacks in MIPv6. As part of developping a proposal
for that would presumably require the type of analysis that you are pointing
out.
But, as pointed out in my original email on the subject, any such proposal
for *using* the reserved bits for something, would need to go through
the normal IETF standards track process.
Reserving the bits just requires the analysis whether the cost of
carving off the bits is worth the potential benefits of being able to
use them for something in the future.

Is that more clear?

   Erik

---

From: Alberto Escudero-Pascual <[email-masked]>
Date: Wed, 13 Mar 2002 10:51:45 +0100 (CET)

I agree of the potencial benefits of reserving bits in the IID  for future
"useful" use in the future, specialy in the mobility area. In that sense,
i will like any references to EUI-64 based identifiers and the use of u/l
bit being removed from 2473 as being already a proposal for making use of
one "bit".

So my suggestion is option 4:  to reserve u and g bits (call them
something else, pls) and follow the normal IETF standards track process to
decide the (how to) use of them.

I want to stick to the question of Erik but i argue why nodes for example
that want to use a privacy extension (RFC3041) have to indicate that their
IID is not EUI-64 based and hence the use of the privacy extension is
observable.

/aep
--
--------------------------------------------------------------------------
That you are not paranoid, it doesn't mean that they are not watching you!
http://www.it.kth.se/~aep

---

From: Steve Deering <[email-masked]>
Date: Wed, 13 Mar 2002 10:43:40 -0800

>IID is not EUI-64 based and hence the use of the privacy extension is

Alberto,

The u bit in the current IID definition indicates whether or not the
IID can be considered globally unique.  The zero value (implying *not*
globally unique) is used not only for randomly-generated ("privacy")
IIDs but also for manually-assigned IIDs, and IIDs assigned via DHCP
that are not derived from the node's IEEE-802 or EUI-64 address.  In
other words, u=0 does *not* mean randomly generated; it means not-
globally-unique.

Steve

---

From: Alexandru Petrescu<[email-masked]>
Date: 13 Mar 2002 21:02:00 +0100

Steve Deering <[email-masked]> writes:
> IID can be considered globally unique.

I'm trying to fit the IMEI into one of:

      Links or Nodes with IEEE EUI-64 Identifiers
      Links or Nodes with IEEE 802 48 bit MAC's
      Links with Non-Global Identifiers
      Links without Identifiers

and I can not fit into any, since it looks than an IMEI is global but
is neither an EUI-64 identifier, nor an IEEE 802 48 MAC address.
However, the link can not be considered as a link without
identifiers[*].

IMEI being global I'm tempted to touch the u bit (universal/local).

IMEI has nothing in it that could influence the g bit
(individual/group), but further investigation is necessary probably.

Alex

[*] or can it?  I guess that phones have IMEI's but their peers at the
    other end of the link (GSNS/SGNS) don't.

  When trying to
code other identifiers into Modified EUI-64, I wonder whether the
individial/group bit should also be set/reset, in addition to the
universal/local bit.

Also, why EUI-64 was adopted as basis and not any other?  I understand
that this easily covers 802 LAN's, but why not something more agnostic
like 

If it was chosen
as the preferred coding for Interface ID's for global unicast
addresses, and as such as an umbrella for other identifiers, was

I understand that
Modified EUI-64 is to be used with all global unicast addresses 

  The zero value (implying *not*

---

From: Alberto Escudero-Pascual <[email-masked]>
Date: Wed, 13 Mar 2002 22:04:34 +0100 (CET)

Steve,

Let me clarify my point:
    u=0 => RFC3041, Manual, DHCPv6 or RFC2472 (4.1)
RFC3041 => u=0

What i am trying to say is that despite that u=0 doesn't necessary mean
that RFC3041 is in use. In practice, it could be the case that a high
number of those IID are using RFC3041 and hence the anonimity set is not
going to be big enough. In an environment where it is known not to be
DHCPv6 we end with P(u=0 => RFC3041) ~ 1.

I still haven't seen a strong justification of why a IPv6 address should
include a bit "claiming" its global uniqueness. I know it is a loooong
time discussion but still i don't see that is justified.

I rather prefer an approach that RFC3041 is the default for all the nodes
and the nodes that want to "opt-in" to have a global unique IID are free
to do it so.

I want to stick to Erik's question and i agree in the value of having
certain reserved bits in the IID but "how to use those bits" and "its
collateral  implications" (for privacy observability for example) should
be discussed out of RFC2473.

Agreed?

/aep

---

From: Robert Elz <[email-masked]>
Date: Thu, 14 Mar 2002 17:28:46 +0700

Date:        Wed, 13 Mar 2002 10:43:40 -0800
    From:        Steve Deering <[email-masked]>
    Message-ID:  <v04220804b8b54ccaa44e@[10.34.255.54]>

  | The u bit in the current IID definition indicates whether or not the
  | IID can be considered globally unique.

If that were to be true, then we would require u==0 in all IPv6
addresses, as there's no possible way for anyone to know if their
IID is globally unique or not.

We don't even need to resort to postulating manufacturing errors
(sloppiness, whatever) to see that the 'u' bit defined this way is
useless.  Though that is certainly part of the potential problem.

The obvious case that breaks this is address reassignment.   That is,
I have some system or other, it has used autoconfig, and allocated itself
an EUI-64 based address, and so, following the rules, has set u==1.

Then the system's net interface breaks in some way (which might mean that
the switch it is connected to breaks, not necessarily the hardware in the
system).   I desire my DNS advertised address to keep on working, so I
assign that address to another interface in the system (or perhaps I install
some new interface type, replace a 100baseTX with GigaE or something).
As I want to avoid all service disruption, this interface gets the
IPv6 address that the system has always had.   The same IID.   And because
the address always had u==1 in the past, it has to keep u==1 now.

Sometime later, my old interface card, with its burned in MAC addr, is
plugged into some other system, connected most likely to some distant
net (distant enough), it does its DAD, finds it can use the address
based upon the EUI from the card, and does so, u==1.

Now we have two systems both using IPv6 addresses with u==1, and both
with the same IID.  Thus, u==1 does not imply a globally unique IID,
and cannot.

The only way we could change that would be to refuse to allow an address
to be used which didn't match the IEEE addr of the card, if it has u==1.
That is, all stacks everywhere (including that in all those shipping XP's)
would have to enforce that rule.   Some hope (too late...).

But I'd object to any attempt to do that in any case, even if it were
feasible.  There's no current use for globally unique IIDs - they're
just a frill "it looks like we can get this for free, so let's define it".
Adding mechanism for no purpose, and while doing so, prohibiting reassignment
of addresses (which is useful functionality) would be absurd.

Not only is there no use for globally unique IIDs currently, it is unlikely
there ever will be one.   No IPv6 address is required to have one of those,
so nothing can ever depend on their existence (and with more and more people
jumping on the "privacy address" band waggon - for reasons that aren't clear
to me, but that's beside the point - it seems that less IPv6 addresses will
have u==1 than might have initially seemed likely).   Further, even if you
find an address with u==1, there's no way to know if it really is globally
unique - there's no testing mechanism - so it would be unreasonable to
rely on its uniqueness for anything important.

So, let's just end this pretence that u==1 has any special meaning, and
revert to the earlier situation, where we no natural EUI-64 is going to
have (the inverted) u==0, so we define things like randomly generated
addresses to always set u==0, so that there's no chance that someone's
randomly generated address is going to be occupying your EUI-64 address
space on your link (the chance is tiny anyway, this removes it completely,
and makes it reasonable for a system using autoconf of EUI-64 based addresses
to simply give up and cry if its DAD fails, rather than requiring a recovery
mechanism).

Finally - if there were to be any kind of reasonable way to test an ID for
uniqueness, then we'd be using EIDs now.  Getting unique EIDs was the major
problem that inhibited us from choosing a protocol that used them (8+8
being one of the contenders - the nearest to IPv6).  And that was a problem
when the EID would have been completely under our control, and so could
have had any properties we desired, unlike EUI-64's, that we're just stuck
with.

kre

---

From: Alberto Escudero-Pascual <[email-masked]>
Date: Thu, 14 Mar 2002 12:02:36 +0100 (CET)

Yesterday, i tried to estimate what is the probability of generating a
random interface identifier that looks like a EUI-64 IID without using the
'u' bit at all calculating the worst of the cases.

Let's take the worst of the cases, that all the EUI-64 based IPv6
current devices are in the same room.

- Today there are 5692 company_id assigned by IEEE
- Let's imagine that all of them are Ethernet devices
- Let's imagine that the 5692*(2^24) IPv6 devices are in the same place
running stalessadress autoconfiguration

The probability of generating a random IID that "looks like a EUI-64" is
P=1-[2^48-(5692*2^24)/2^48]=0.00034

I beleive that EUI-64 based, Random, Manual, DHCPv6 ... should not carry a
bit "claiming" how they were generated to provide a "claim" of uniqueness.
Is the porpouse of DaD to detect only the duplicate random interface
identifiers then?

There is a quantitative and qualitative difference in reserving one bit
for RR or CryptoIID to enhance mobile security and even handover
performance or to reserve one bit (u) to "CLAIM" uniqueness.

PD. I funny plot of the distribution of the IEEE OUI is available at:
http://www.it.kth.se/~aep/ieee-oui.ps

/aep

---

From: Markku Savela <[email-masked]>
Date: Thu, 14 Mar 2002 14:25:03 +0200

> From: Alberto Escudero-Pascual <[email-masked]>

> There is a quantitative and qualitative difference in reserving one
> bit for RR or CryptoIID to enhance mobile security and even handover

Uhh.. RR bit? I've not followed mobile-ip list too closely. But, if
this bit is supposed to be reserved within "EUI-64 framework", I must
protest! Because, ...

... it would limit home agents only to those hosts that have IPv6
address format that mandate EUI-64 interface id. Wouldn't this prevent
using 6to4 address as home address? It would also exlude all
future non-EUI-64 address formats (or force everyone to use EUI-64).

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Mar 2002 17:37:31 +0100 (CET)

> future non-EUI-64 address formats (or force everyone to use EUI-64).

Markku,

6to4 addresses have a 64 bit interface ID with the same semantics
as other interface IDs.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Mon, 18 Mar 2002 20:28:23 +0100

In your previous mail you wrote:

   > IID can be considered globally unique.
   
=> can I assume you didn't read draft-dupont-ipv6-imei-00.txt?
(you should and I should have answered before :-)

   
=> my proposal is to use u=1,g=1 for IMEIs. Obviously this collides
with Erik's idea...

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 18 Mar 2002 21:18:19 +0100

=> what exactly do you mean by "reserve":
 - make them not available at all?
 - enforce some control/rules on availability?

   I think our choices are:
   1. Do nothing
   
=> if reserve is available following to be defined rules I am in favor of 3.

   It would be good to try to make progress on the mailing list on
  this question otherwise it's likely to appear on the agenda in the
  meetings next week :-)
   
=> so we'll get a hot (and not too long, please :-) discussion thursday
morning.
BTW I have an objection to the "IPv6 over foo" only way: this assumes
there is a real link. With mobile IPv6 there are some scenarios where
the home link is purely virtual, so there is no foo...

Thanks

---

From: Steve Deering <[email-masked]>
Date: Mon, 18 Mar 2002 12:52:14 -0800

>(you should and I should have answered before :-)

That's normally a safe assumption, but in this case I actually did read
your draft.  My statement, which you quoted above, is not in conflict
with your proposal, so I don't understand what point you are making.

>=> my proposal is to use u=1,g=1 for IMEIs. Obviously this collides

Yep.

Steve

---

From: Francis Dupont <[email-masked]>
Date: Mon, 18 Mar 2002 22:01:42 +0100

>   > IID can be considered globally unique.

=> I apologize because this is not clear: I answer to a mail from
Alexandru who cited you.

   
=> the question is addressed to Alexandru...

Thanks

---

From: Markku Savela <[email-masked]>
Date: Mon, 18 Mar 2002 23:13:26 +0200

I'm somewhat puzzled by this thread... has it been decided that IPv6
address is 64+64, and that latter 64 is EUI-64 format interface ID for
all current and future IPv6 addresses?

If not, I cannot see what is the point of assigning these bits from
EUI-64 and expect them to be valid for other ID formats? They can only
be guideline for certain link layers, but have not meaning between end
nodes.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 18 Mar 2002 22:32:24 +0100

=> this was decided for all unicast addresses which don't begin
by 000 bits. Look at last RFC 2373 revision, aka addr-arch-v3:
draft-ietf-ipngwg-addr-arch-v3-07.txt

but it seems the decision is not yet very decided even if the draft
has been in last call since months.

Regards

---

From: Bob Hinden <[email-masked]>
Date: Mon, 18 Mar 2002 13:57:16 -0800

Markku,

>all current and future IPv6 addresses?

Yes.  The use of 64 bit interface ID's is defined for prefixes 001 through 
111 ( except for multicast addresses), in RFC2373 "IP Version 6 Addressing 
Architecture" published July 1998.  See section 2.4.  The text regarding 
EUI-64 has been clarified in <draft-ietf-ipngwg-addr-arch-v3-07.txt>.

Bob

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Mar 2002 23:15:48 +0100 (CET)

>  - enforce some control/rules on availability?

See my first email on the subject. The summary is:
Reserve for future use; any future use requires an standards track RFC.

> the home link is purely virtual, so there is no foo...

What does IPv6 over foo have to do this subject?

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Mon, 18 Mar 2002 23:27:39 +0100

=> fine, we seem to be in violent agreement.

   
=> there are some answers to your next step message arguing the whole
stuff should be moved to "IPv6 over foo" documents. My point is this
won't work when there is no foo... So I am in favor to keep the modified
EUI-64 stuff in the RFC 2373 revision.

Regards

---

From: Markku Savela <[email-masked]>
Date: Tue, 19 Mar 2002 00:27:30 +0200

> EUI-64 has been clarified in <draft-ietf-ipngwg-addr-arch-v3-07.txt>.

Ooops... :-} I guess I read some older RFC first, and the change never
registered on reading updates (and after implementing the first
version).

I have all the time falsely assumed that IPv6 address for a specific
link layer was n-bit prefix and 128-n bit identifier, where n could be
almost anything between 0 and 64.

So, there is only those addresses starting with 000 where anything is
possible. Thats lots of addresses still, so maybe I keep the
implementation as it is :-)

---

From: "Philip J. Nesser II" <[email-masked]>
Date: Mon, 18 Mar 2002 17:14:35 -0600

RFC 793 states in section 3.1 that:

"The checksum also covers a 96 bit pseudo header conceptually prefixed
to the TCP header.  This pseudo header contains the Source Address, the
Destination Address, the Protocol, and TCP length."  

How are people calculating the checksums on IPv6/TCP packets in current
implementations?  I assume that it is being done uniformly since people
seem to interoperate, but for the life of me I can't seem to find it
written down in any RFC.  Can someone please point me to the appropriate
reference?

Thanks,

Phil

---

From: "Sean Lin" <[email-masked]>
Date: Tue, 19 Mar 2002 11:29:13 +1200 (NZST)

Hi Phillip,
	Basically the checksumming in IPv6 and IPV4 are pretty much the 
same; same method but different pseudo-header. The format of the ipv6 
pseudo-header is in RFC2460.

Regards,
Sean

> "The checksum also covers a 96 bit pseudo header conceptually prefixed to
> the TCP header.  This pseudo header contains the Source Address, the

-------------------------------------------------------------
Sean Lin                 27 Nazareth Avenue
Software Engineer        PO Box 8011
Allied Telesyn Research  Christchurch
phone +64 3 339 3000     New Zealand
fax   +64 3 339 3002     email: [email-masked]
                         web: http://www.alliedtelesyn.co.nz/
-------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Tue, 19 Mar 2002 07:14:24 +0200

> From: "Sean Lin" <[email-masked]>

> pseudo-header is in RFC2460.

Minor additional tidbit...

...you can use IPv6 pseudoheader for BOTH IPv4 and IPv6, if you use
IPv4 mapped addresses for IPv4.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Alexandru Petrescu<[email-masked]>
Date: 19 Mar 2002 12:23:20 +0100

> => the question is addressed to Alexandru...

I guess I have read it before I suggested an improvement on the coding
of decimal IMEIs into hexa.  There's an email very early in the
thread, but much later than your original post, ah too many emails.

After this long deviation, it would be nice if we could get back to
this thread's original subject on reserving bits in Interface ID's, of
RFC2373, updated by draft-ietf-ipngwg-addr-arch-v3-07.txt.

Since the proposal involves so many unknowns (to me) I think it's good
to be conservative, and if a new reservation happens, then reserve a
quarter only.  In my humble oppinion.

Alex