Subject: Re: a response to "A Simple Solution for IPv6 Multihoming"

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 14 Sep 1999 22:43:42 -0400

In message <[email-masked]>, Bradley Rey
nolds writes:
> > > that is not analogous in the least to the hierarchy imposed in the ipv6
> > > addressing architecture.  cidr only specifies more possible subdivisions
> > > of the addressing space which permits you to aggregate in more flexible
> > > fashion. it does not mandate an aggregation hierarchy in the least.
> > 
> > See RFC 1466.
> > 
> 
> rfc1466 has to do with cidr?

Yes -- it's cited by RFC 1517 as the way allocation should be done to support 
aggregation.
> 
> it mandates an allocation hierarchy, not an aggregation hierarchy.
> aggregation can be done in conformance to the allocation hierarchy,
> but is not necessary.
> 
> people are still free to announce whatever specificity they want.

In theory, yes; in practice, not really.  First, almost everyone currently 
receives addresses in conformance with that policy and its successors, 
precisely to permit aggregation.  Second, some major ISPs won't accept route 
advertisements for overly-long -- that is, unaggregated -- prefixes.

The IPv6 allocation policy is simply a cleaner version of what we are 
currently doing.

Yes, there are bad side-effects.  We'd all love to have multi-homing, portable 
/32s (or /128s), etc.  We -- as a profession -- simply don't know how to do it.

		--Steve Bellovin

--------------------------------------------------------------------
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: Dimitry Haskin <[email-masked]>
Date: Wed, 15 Sep 1999 10:39:43 -0400

Peter,

Apart from location of the routing ID, your proposal is not much
different from the earlier GSE (64+64) proposal of separating endstation
identifiers and routing locators. This proposal was taken seriously but
under scrutiny (please read draft-ietf-ipngwg-esd-analysis-04.txt) the
proposal showed a number of fatal flaws (e.g. hijacking of TCP
connections gets much easier).

----------------------------------------------------------------------
Dimitry Haskin
Lucent Technologies Internetworking Systems

> -----Original Message-----
> From: Peter Tattam [mailto:[email-masked]]
> Sent: Wednesday, September 15, 1999 1:12 AM
> To: Brian E Carpenter
> Cc: [email-masked]
> Subject: Re: a response to "A Simple Solution for IPv6 Multihoming"
> 
> 
> On Tue, 14 Sep 1999, Brian E Carpenter wrote:
> 
> > Peter,
> > 
> > Sure, if someone makes a breakthrough that will be great. I haven't
> > seen it yet though, and people have been looking for many years.
> > 
> >   Brian
> > 
> 
> I put my thinking cap on last night..
> 
> I have a very simple proposal which I would humbly ask be 
> given serious
> consideration.  I did raise a version of it before with Jim 
> but he felt it
> would get the thumbs down.  This is not exactly the same, but 
> draws also on
> ideas from Dan's proposal, so some of the credit I owe to Dan.
> 
> My proposal goes thus.
> 
> 1. Keep the existing CIDR allocation exactly as it is. (not 
> the routing
> policy, this is dealt with later).
> 
> 2. sacrifice one bit of the flow label to define a routing 
> label.  This would
> leave 31 bits available for a routing ID.
> 
> 3.  Use sparingly those 31 bits for a heiarchical routing tree.
> 
> 4a.  Have an extension to the DNS system which defines the 
> *current* mapping of
> the hostname to routing ID.  It is a host's responsibilty to 
> place the correct
> routing ID in the packet prior to transmission.  This is no 
> different in
> security level to existing DNS practice.  The DNS would need 
> interaction to
> reflect the dynamic nature of routing cloud changes.  DDNS is 
> I believe
> suitable for this purpose.
> 
> 4b. An alternative to DDNS would be multiple RRs combined with stale
> route detection to trigger automatic replacement of the 
> routing ID at the
> originating host.
> 
> 5.  The non-site routing cloud then uses this routing ID for 
> interdomain
> routing instead of the regular dest address.  Current 
> practice as used in the
> 6bone for aggregation.
> 
> I believe I can sufficiently flesh out a full implementation 
> of this on paper
> if there is enough interest, but I won't bother if the cost 
> of sacrificing one
> bit of flow label, altering routing practice, and extending 
> Ipv6 stacks to
> cope with the changes are impractical.
> 
> 
> 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: Bob Hinden <[email-masked]>
Date: Thu, 16 Sep 1999 10:35:30 -0700

BR,

>so then why this big debate and address architecture drafting if
>multihoming can work just as well in ipv6 as it does in ipv4.  just
>allocate blocks to regional registries who can then dole out addresses.  
>no structure other than that.  isps aggregate however they see fit.
>
>advertise your /64 out transit provider A and transit provider B and you
>are finished.

We want the routing system to scale.  If we allow anyone who wants one to
get a top level prefix, then we are pretty sure that the routing system
will not scale.  We are designing for a much larger internet.  The core
routing tables would be quite large if every one could advertise a /64.
2^^64 is a big number!

I would also note that it is a lot easier going from an aggregated system
to an non-aggregated, than the other way around.

>i am not arguing against aggregation.  just let the ISPs do it.  they
>have a vested interest in not melting the core.

Good.  We all have a vested interest in not melting the core.

Bob

---

From: Richard Draves <[email-masked]>
Date: Fri, 17 Sep 1999 11:26:40 -0700

> 	The prosaol have a subset of hosts in a multihoming 
> site assigned
> 	with address space from ISP-A and a subset with that from ISP-B.
> 	And under the assumption of aggregation, only ISP-A advertise
> 	it's aggregate (say address-A) to the entire Internet and only 
> 	ISP-B advertise address-B to the entire Internet e.g. 
> ISP-C, ISP-D
> 	ect.  If ISP-A has massive failure, half of the hosts 
> assigned to 
> 	address space from A at the multihoming site is not going to be 
> 	reachable. If ISP-A lost all its connection to ISP-D, then ISP-D
> 	and anything behind it can not reach the hosts in 
> address-A space
> 	of the site.  Same thing applies if ISP-B had massive 
> failure.  So 
> 	the reachability of a multihoming site realies on a 
> single ISP as 
> 	much as that in SMPL's situation.  If anyone claim SMPL 
> does not 
> 	provide reasonable redundancy, then RFC2260/itojun does 
> not do it 
> 	either. 

I thought the RFC2260/itojun approach used prefixes obtained from ISP-A and
ISP-B to number the entire site, ie hosts in the site all have two
addresses?

> 	The Secondary link (tunnel) between ISP-BR-A and E-BR-B has to
> 	be built either on physical link ISP-BR-A to E-BR-A or 
> some links 
> 	between ISP-A and ISP-B. Obviously, one can not use the former
> 	since the tunnel is servered as the backup when the link between
> 	ISP-BR-A/E-BR-A goes down. So the tunnel has to be using links
> 	between ISP-A and ISP-B which will entirely depend on how they
> 	route each other.  If someone worries about link congestion
> 	between ISPs, you can not avoid it here as well.  I think Rob
> 	from Sprint pointed out the same issue in his earlier message
> 	although I have not read it carefully yet.

If the tunnel endpoint addresses are chosen properly (out of the correct
prefixes belonging to ISP-A & ISP-B), won't they automatically be routed
properly over the physical links between ISP-A & ISP-B?

> 	One issue with tunnels is that it will make packets which would
> 	normally fit in max MTU size exceed the max MTU size due to the
> 	adding of IP header for encapsulation. This will cause routers
> 	to waste resource for packet fragmentation which led to very 
> 	poor performance.  Many Tunnel based VPN users suffer from the
> 	problem.

This isn't an issue for v6, is it? The router will not do fragmentation,
instead the path MTU change will get propogated back to the originating
host.

Rich

---

From: Jessica Yu <[email-masked]>
Date: Fri, 17 Sep 1999 15:36:16 -0400

>        I do not know if this will be in place anywhere in the v6 world.
>		                                ^^^^^^^^
>        Would someone comment on this? 

I really meant everywhere instead of anywhere.  
Also, can someone tell me if the implementation is avaialble now?
Thanks!

							--Jessica

---

From: Jessica Yu <[email-masked]>
Date: Fri, 17 Sep 1999 15:49:01 -0400

>>
>>>> 	The prosaol have a subset of hosts in a multihoming  site assigned
>>>> 	ISP-B advertise address-B to the entire Internet e.g.  ISP-C, ISP-D
>>>> 	ect.  If ISP-A has massive failure, half of the hosts assigned to 
>>>> 	and anything behind it can not reach the hosts in address-A space
>>>> 	of the site.  Same thing applies if ISP-B had massive > failure.  So 
>>>> 	single ISP as much as that in SMPL's situation.  If anyone claim SMPL 
>>>> 	does not provide reasonable redundancy, then RFC2260/itojun does 
>>>> 	not do it either. 
>>>
>>	I do not believe RFC2260 intend to have each host assigned 
>>	with multiple IP addresses. itojun's extention does not 
>>	require each host be assigned with multiple IP addresses.

>	RFC2260 does not intend to, but draft-itojun-ipv6-2260 does.
>	see 4.2.  The document does not *mandate* assignment of two addresses,
>	though.

	We are saying the same thing. That is good that we have the
	same understanding. 

>>	If multiple IP address per host is a requirement for that
>>	proposal, then we are opening another big can of worms. 
>>	Besides, with multiple address per host, need to use tunnels
>>	as backup diminishes.

>	Site administrators are free to choose address assignment.
>	If you do not assign both, the node will not be reachable when
>	one of your ISP is totally unusable.  If you assign both prefixes
>	to a node, a node needs to do some source address selection.

	Agree. Source address selection could be a tough cookie to bite.
	More study is needed to exactly how to do it. It may also presents
	issues for DNS, etc.  

	If a site choose to not assign multiple address, then SMPL might
	be attractive since it is simple to manage (no tunnles) thus
	less chance to mess up and provide comparable funcationality such 
	as redundancy, load sharing,etc. 

>itojun

						  Thanks!
						--Jessica

---

From: Dimitry Haskin <[email-masked]>
Date: Fri, 17 Sep 1999 16:20:07 -0400

> Also, can someone tell me if the implementation is avaialble now?

Hosts that don't implement the Part MTU discovery should limit their
packet sizes to 1280
octets. For all practical purposes it leaves rooms for possible
encapsulations.  Hosts that send packets larger than 1280 bytes should
be prepared that such packets may not get through.
V6 routers are required to implement their portion of the Path MTU
discovery, i.e. sending Packet-Too-Big ICMP messages. V6 routers don't
fragment transit traffic, if this is your question.

---

From: Richard Draves <[email-masked]>
Date: Fri, 17 Sep 1999 12:54:10 -0700

> Also, can someone tell me if the implementation is avaialble now?

Yes, it will be in place everywhere - it's a standard part of IPv6. As far
as I know, it's how all implementations work today. Certainly that's how MSR
IPv6 will behave when forwarding into a tunnel.

Rich

---

From: Richard Draves <[email-masked]>
Date: Sun, 19 Sep 1999 22:30:48 -0700

> > I don't know either, but I suspect that the latent demand may be
> > significant.
> > 
> 
> Based on what?

I suspect that as businesses come to rely on the internet (business
processes like dealing with customers & suppliers, running VPNs, etc), they
will be increasingly interested in multi-homing.

Rich

---

From: [email-masked]
Date: Mon, 20 Sep 1999 21:08:38 +0100

> From:	Jessica Yu [SMTP:[email-masked]]
> Sent:	Monday, September 20, 1999 7:37 PM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]
	....

> 	I gather that you are saying that there could be more than
> 	one multhoming solutions.  The selection of such mechanism
> 	is largely depending on customers' requirements such as,
> 	the level of desirable redundancy and financial constrains
> 	(this could vary from customer to customer) and ISPs' own 
> 	considerations such as managibility, scalability and charging 
> 	mechanism.  I agree.
> 
	Exactly! and I am glad you agree.

> 	My sense is that the requirements of many multihoming sites would 
> 	be: a) reasonable redundancy and b) less complexed solution.  
> 
	Many but not necessarily all. In any case (as someone frequently
sais) "the market will decide". As others also have said multihoming applies
(or may apply soon) to many different levels in the internet i.e: single
node, Home network, small site, large site, ISP etc etc...

> 	Since most of such sites do not have in-house expertises to deal 
> 	with on site complexed configuration and network management and 
> 	neither can they afford to hire one.  
> 
	Some, however, buy this as a service and let their ISPs manage it
(if its is cheaper than in-house expertise). Some big customer sites also
have a lot of expertise (more than some ISPs even!) In anycase we should not
try to guess the business case but only to adequately describe the different
options and technical solutions so people, sites and ISPs know what they get
into when they pick one up.

	On a different note I will agree with you that some of the
multihoming proposals are going to be very complex in management terms for
some time (e.g: itojun'sRFC2260 + Router Renumbering). IMO, this is largely
due to the embryonic state of Internet operations and management (no offence
to the management folks!)

	What I am saying is that as the Internet matures, it takes up new
services  (i.e: multicast, QoS, VoiP, VPNs, IPSEC etc) and as such it
becomes more complex. More complex systems demand more complex management
and thus I expect that complex multihoming solutions will be supported
sooner or later as management systems develop... 

	Regards
	George

---

From: [email-masked]
Date: Mon, 20 Sep 1999 21:16:23 +0100

> Sent:	Monday, September 20, 1999 6:36 PM
> To:	Magnus Ahltorp
> Cc:	Jessica Yu; Ben Black; [email-masked]
> >>       In summary, RFC2260/itojun does not seem to provide better
> >>       redundancy than SMPL. The problem associated with tunnel
> mechanism
> >>       should not be overlooked.
> >
> >Yes it does, since you can assign multiple addresses to each host.
> 
> 		
> 	If multiple addresses per host is used then there is not 
> 	necessary of using tunnle to gain redundancy.  
> 
	In fact it is because using the tunnels allows existing connections
to be saved on link failure (just needs a bit more clever routing in the
site).

	Also as a special(?) case a site might multihome to two ISPs from
the SAME gateway router, this makes some of the config easier.

	George

---

From: Steve Friedman <[email-masked]>
Date: Wed, 22 Sep 1999 14:50:31 -0400

---

From: Dan Lanciani <[email-masked]>
Date: Sat, 25 Sep 1999 15:01:15 -0400 (EDT)

[email-masked] (Niels Möller) wrote:

|I also think it would be a good thing to clarify exactly what level of
|security is wanted for (in)secure traffic. This does seem like a
|strange thing to be talking about, but I suspect it is important.

I agree that it is very important.  I found myself having great difficulty
responding quantitatively with respect to my portable identifier proposal
to concerns about "less" security because the delta between insecure and
more insecure is both small and elusive.  If you have, say, 10 quick and
easy ways to interfere with a tcp connection and then you make a change such
that there are now 11, has the security really gone down?

|What level of security is it reasonable to expect from the network and
|transport layers? As far as I can tell, we'd like it to at least not
|be trivial for an attacker to cause the tcp session to die. Is that
|true for ipv4?

No, it's pretty trivial under IPv4 to kill a session.  The net seems to
go about its business in spite of this...

|And is it correct that simple "anonymous"
|authentication as described above provides similar (or better)
|protection also in the presens of things like binding-update?

Protecting against everything but man-in-the-middle attacks certainly
seems to be a step up since as a practical matter man-in-the-middle
attacks (at least those not originating in one of the organizations
of the endpoints) are harder for random users to implement.  On the
other hand, it isn't obviously worthwhile to implement such a solution
in parallel to full crypto authentication:  you add a lot more code and
protocol complexity for an option that many would not understand as
significantly different from "real" authentication.

				Dan Lanciani
				[email-masked]