Subject: Dialup issues

From: Magnus Ahltorp <[email-masked]>
Date: 21 Jul 1999 19:56:42 +0200

Are there any documents describing how to assign addresses to dialup
lines?

Assigning /64 to dialup lines seems like overkill, yet people want to
run some sort of network at home with all the machines having global
addresses.

/Magnus
--------------------------------------------------------------------
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: "Matt Crawford" <[email-masked]>
Date: Wed, 21 Jul 1999 15:45:32 -0500

> run some sort of network at home with all the machines having global

You can give a single address with PPP.  The next step from there is
a /64.  And it makes sense, because isn't this exactly one sort of
customer for whom autoconfiguration is very important?

It would make sense to leave the endpoints of the link itself without
global addresses and allot the /64 to the subnet behind the dialup
peer.
				Matt

---

From: Peter Tattam <[email-masked]>
Date: Thu, 22 Jul 1999 14:31:14 +1000 (EST)

> run some sort of network at home with all the machines having global

Yeah.  That's what I ended up doing to get RA to work correctly on a Cisco.
Assigning a /64 to each line may use up addresses a little too fast.
Generally, I would prefer to assign a /64 to a group of dialup lines, and let
the autoconfig sort out the clashes.  I would assum the routers could then
assign the remote end point a /128 and keep the server end as unnumbered (much
the same as is done in Ipv4).  Alternatively, one could use a set of /126
subnets, but I am told this breaks a few Ipv6 implementations that have
difficulties with prefixes > 64.

As an aside, are Ipv6 implementations supposed to fully implement prefixes >
64.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Steve Deering <[email-masked]>
Date: Wed, 21 Jul 1999 23:34:57 -0700

>run some sort of network at home with all the machines having global

There were some back-of-the-envelope studies done during the IPng
selection process that indicated that 48 bits would be enough to
address something like every enterprise, residence, and automobile in
the world, based on UN population predictions for the year 2025 or
thereabouts.  This included accounting for the inevitable inefficiency
of hierarchical addressing, but assumed some discipline in the allocation
of those 48 bits (e.g., not forcing all hierarchical boundaries to fall
on a multiple of 4 or 8 bits).  Thus, I see no inherent problem in
allocating as much as a /48 worth of space to a dial-up connection to
a home; that would allow the customer to have many home subnets (e.g.,
a "body net" of wearable computers for each person living there, a
network in each of the homes's vehicles, plus various non-mobile nets,
each using EUI64- based stateless autoconfiguration for transparent
plug-and-play.  Though I suppose by the time that's common, we won't
have to put up with silly "dial-up" connections any more...

However, I understand that the idea of giving each home 80 bits worth
of address space is hard to fathom by most of us who are suffering
from IPv4's address scarcity (kinda like people in the old Soviet Union
not being able to comprehend the abundance of an American supermarket).
So maybe starting with /64s for dial-up connections is a reasonable
initial step (like the way people who have been starving should be
careful about overeating when they finally find food), but let's not
worry about trying to conserve /64s.  There are a *lot* of them.  And
the last thing we want is for IPv6 users to feel they need to install
an IPv6 NAT box to get a bigger address space than they can get from
their ISP(s)!

At 2:31 PM +1000 7/22/99, Peter Tattam wrote:
>As an aside, are Ipv6 implementations supposed to fully implement
>prefixes > 64.

Yes.  Most of the unicast address space has been specified to have a
64-bit interface ID field, but not all of it.  IPv6 implementations
ought to be able to handle prefixes of any length.

Steve

---

From: Bill Manning <[email-masked]>
Date: Wed, 21 Jul 1999 23:58:59 -0700 (PDT)

> As an aside, are Ipv6 implementations supposed to fully implement prefixes >

Citing an old addage: "Be Conservative in what you send, Liberal in what
you receive" and noting that there remains the option to evolve how the 
address architecture looks, (noting that IPv4 underwent at least three
iterations in 25 years and IPv6 has done the same number in 5) I think
it would be prudent to allow flexability.  If it was me, I'd treat the
whole 128 bits as CIDRizable.            

-- 
--bill

---

From: Francis Dupont <[email-masked]>
Date: Thu, 22 Jul 1999 10:49:42 +0200

In your previous mail you wrote:

=> since the 64-bit interface ID introduction I believe there are only
three cases for prefix lengths:
 - less than 64 bits (they should not be used for link prefixes)
 - 64 bits (link prefixes)
 - 128 bits (cheap point-to-point link prefixes)
I think you can use 128 bit or 64 bit prefixes for PPP, *not* 126 or 124 bits.

Regards

[email-masked]

PS: my implementation rejects prefix-infos in router advertisements
with length < 16 or (length > 64 and length != 128) both in router
and host codes since yesterday (I work on prefix discovery for PPP
because I had some problems with Unix ifconfig which wants two
addresses (local and peer) for point-to-point links... I advise
to use the router address stuff (from mobile I-D, 6.2, page 34)
on the router side in order to give peer addresses).
--------------------------------------------------------------------
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: Ignatios Souvatzis <[email-masked]>
Date: Thu, 22 Jul 1999 11:23:02 +0200

> ought to be able to handle prefixes of any length.

Most of? I thought that, err... 1/8 were special addresses including 
multidcast, 1/8 were global aggregatable addresses with the /64 property,
and all others reserved for future use?

Regards,
	-is

---

From: Magnus Ahltorp <[email-masked]>
Date: 22 Jul 1999 11:35:19 +0200

> an IPv6 NAT box to get a bigger address space than they can get from

The proposal I was going to make was to see a group of dial-ip
connections as one /64, and use DHCP to allocate addresses. I haven't
yet thought about the neighbour discovery issues involved in sharing a
/64 in this way, since I wanted to know if someone else had been
working on it.

Would it be interesting to study subnet-sharing, or should I just
consider it a Bad Thing and forget about it?

/Magnus

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jul 1999 08:18:34 -0500

Also, we have a large supply of /64s so this really shouldn't be
a problem.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]

---

From: Steve Deering <[email-masked]>
Date: Fri, 23 Jul 1999 07:39:03 -0700

>and all others reserved for future use?

Page 7 of the IPv6 Addressing Architecture (RFC 2373) says:

      (2) 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.  See section 2.5.1 for
          definitions.

This covers almost all of the unassigned part of the address space.  The
only parts that do not fall under this rule are the multicast addresses
(prefix 11111111) and the one-eighth of the space that has prefix 000
(some of which is assigned for embeddings of other address spaces,
e.g., IPv4, NSAP, IPX).

Steve