Subject: (IPng 6462) Questions about PPP over Ipv6.

From: [email-masked] (Peter R. Tattam)
Date: Tue, 15 Sep 1998 20:35:58 +1100

Some of you may know that I've just released a beta for Trumpet Winsock 4.1 
last week.

I'd like to work on PPP but I can't figure out what the spec requires for 
header compression.  I see an internet draft for generic header compression 
but I'm not sure if that's supposed to be the standard that everyone's 
operating to.

Can someone point me in the right direction?

Also, one other question...  the token for PPP is 32 bits.  It seems a little
small, and since it differs from the token size of 48 bits for ethernet, it 
makes stateless address config somewhat inconsistent with what might be 
advertised on a LAN.  Can one assume that the other end of the PPP link will 
be advertising routes with the correct size prefix for autoconfig?   What 
would be the defined method of allocating a PPP prefix from a site's prefix.  
One obviously has to choose addresses that won't clash with existing ethernet 
addresses.

It seems to me that stateless address config only works adequately if the 
universe of known interfaces all share the same address size, or that if there 
are mixed address size, that a smaller addresses must be concatenated with an 
address prefix to pad it out to the largest address size with the prefix being 
chosen uniquely.  This begs the question, is there a standard prefix for PPP 
which prevents the PPP address from clashing with the known universe of 
Ethernet addresses.  (It would be rather expensive on ethernet addresses as it 
would require 256 ethernet manufacturer allocations.)

I see in some of the internet drafts that addresses used for stateless config 
are padded out to 64 bits before being appended to the site prefix.  Is this 
designed to deal with the problem (I presume so)?  If so, when is the practice 
likely to come into play and is there a transition mechanism for the current 
practice of *only* accepting prefixes that make the total add up to 128 bits?

Pardon my ignorance if these are standard newbie questions.

Peter

--------------------------------------------------------------------
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: Keith Owens <[email-masked]>
Date: Tue, 15 Sep 1998 21:16:09 +1000

>One obviously has to choose addresses that won't clash with existing ethernet 

RFC 2373, end of section 2.4 says "The format prefixes 001 through 111,
except for Multicast Addresses (1111 1111), are all required to have to
have 64-bit interface identifiers in EUI-64 format".  Section 2.5.1
describes EUI-64, including the fact that where a global token is not
available (covers serial links amongst others) that the "u" bit should
be inverted.  So "inet6 addr: 3ffe:900:6::6/64 Scope:Global" is quite
valid for a tunnel or serial link.

Just take your /64 prefix and append ::n where n is a small number to
the end to create serial link end points, it will never conflict with
ethernet.  Keeping n unique within your site is your problem :).

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 15 Sep 1998 11:57:47 -0500

> small, and since it differs from the token size of 48 bits for ethernet, it 

Doh!  I was afraid this would happen.  The new documents for
IPv6-over-ethernet and -fddi have been sitting in the RFC editor's
queue so long that some implementors don't know they're there.

(In fact, the drafts have technically expired, but perhaps the i-d
editor has them on life support since the IESG approved them.)

The interface identifier is now generally 64 bits long.  For 802
media, it's derived from the MAC address using the IEEE-specified
procedure of inserting FFFE (hex) in the middle.

> Ethernet addresses. 

See draft-ietf-ipngwg-ipv6-over-ppp-06.txt, recently apporvied by the
IESG to supersede 2023.
______________________________________________________________________________
Matt Crawford                    [email-masked]                     Fermilab
"A5.1.5.2.7.1. Remove all classified and CCI boards from the COMSEC equipment,
thoroughly smash them with a hammer or an ax, and scatter the pieces."
--------------------------------------------------------------------
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]
--------------------------------------------------------------------