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

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

>> 	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?

	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.
	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.

>> 	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?

	Yes. It will be routed on one of the links between ISP-A and 
	ISP-B. But this does not change my point above. 

>> 	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.

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

						Thanks!
						--Jessica
--------------------------------------------------------------------
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: [email-masked]
Date: Sat, 18 Sep 1999 04:32:54 +0900

>	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.

>	Besides, with multiple address per host, need to use tunnels

	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.

itojun