Subject: RE: About the NAP/ISP distinction in the usage-scenarios draft...

From: <[email-masked]>
Date: Wed, 8 Jan 2003 16:45:20 +0200

Hi all and Happy New Year!

The multi-method authentication happens in serial and in the same "session", thus it doesn't fit for all cases.

As PANA is carried over IP, I never really understood the requirement for the PAA to be in the same link than PaC. For discovery purposes this is not necessary, especially in cases where PAA initiates the authentication/authorization. Usage scenario below.

When PaC utilizes multiple ISPs, the auth. happens when PaC starts to access the ISP's network.

             . . . . . . . . . . . . . .
             .             .           .        
   PaC . . . AR--PAA   |  AR--PAA  |  AR--PAA  |
                  |    |       |   |       |   |
                 AAA   |      AAA  |      AAA  |
               (NAP)   |   (ISP)   |   (ISP)   | 

- Dan

> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 19 December, 2002 18:19
> To: Alper E. YEGIN
> Cc: MORAND Lionel FTRD/DAC/ISS; Yoshihiro Ohba; Patil
> Basavaraj (NET/Dallas); [email-masked]
> Subject: Re: About the NAP/ISP distinction in the
> usage-scenarios draft...
>
>
> I have one additional issue in mind that would affect the requirements
> for EAP authentication policy.
>
> Assume that multi-method EAP authentication is used for providing
> multi-level authentication (i.e., NAP authentication and ISP
> authentication).  If the EAP method performed for ISP authentication
> fails, but the other EAP method performed for NAP authentication
> succeeds, should the entire EAP conversation fail?  I think EAP should
> be flexible enough to allow the policy in which EAP-Success message is
> returned even when some of the methods fails.
>
> Yoshihiro Ohba
>
>
> On Fri, Dec 13, 2002 at 03:19:28PM -0800, Alper E. YEGIN wrote:
> >
> > Lionel,
> >
> > I think it'd be useful to understand the semantics of each
> authentication,
> > and the expected actions taken by the client and the
> network after each one
> > is
> > completed.
> >
> > For example:
> > 1- what does it mean to the NAP when a client gets
> authenticated? What
> > actions
> > should be taken (e.g., how are the filters updated, where
> are they updated,
> > etc.)?
> >
> > 2- What can or cannot the client do after this first round of
> > authentication?
> >
> > 3- same question as 1, but for ISP authentication.
> >
> > 4- same question as 2, but for ISP authentication.
> >
> >
> > alper
> >
> >
> >
> > > Hi Alper,
> > >
> > > I think that, in the described scenario, the principle of
> two successive
> > authentications (one per AAA backend) may appear obvious. However,
> > considering a single PAA handling the both authentication
> procedures, there
> > is an issue concerning the use of the DI.
> > >
> > > The most intuitive idea is to reuse the same DI for both
> authentications
> > and to use different sets of credentials
> (identifier,authenticator) supplied
> > by the client. But according to the current draft on the
> PANA requirements
> > and as Yoshihiro said, it seems that it should not be possible.
> > >
> > > On the other hand, the alternative would be to use
> different DIs but the
> > PAA would create distinct bindings, and so distinct
> instances in this case,
> > that would make the network access control more complex.
> > >
> > > A simple solution here could be to allow in the PANA
> requirements the
> > association of one single DI with different PaCs, but this
> may raise up some
> > other previous/new concerns.
> > >
> > > What do you think about this?
> > >
> > > Best Regards,
> > >
> > > Lionel
> > >
> > >
> > > >-----Message d'origine-----
> > > >De : Alper E. YEGIN [mailto:[email-masked]]
> > > >Envoy？ : jeudi 12 d？cembre 2002 00:16
> > > >？ : MORAND Lionel FTRD/DAC/ISS;
> [email-masked]; Yoshihiro
> > > >Ohba; [email-masked]
> > > >Objet : Re: About the NAP/ISP distinction in the usage-scenarios
> > > >draft...
> > > >
> > > >
> > > >
> > > >Hello Lionel,
> > > >
> > > >Thanks for bringing this scenario up.
> > > >
> > > >In the case both NAP and ISP requires their own independent
> > > >client authentication, I presume we can still envision both
> > > >using the same PAA on the BAS (broadband access server).
> Does this
> > > >makes sense?
> > > >
> > > >For NAP authentication, PAA consults with AAA backend in NAP
> > > >network. For ISP authentication, PAA consults with AAA backend
> > > >in ISP network.
> > > >
> > > >Somehow the client needs to know (or discover??) that it has
> > > >to go through the authentication twice. Discovery might be tricky
> > > >because something has to tell the client that the second one
> > > >is meant for the ISP, etc.... If the client knows it has
> to do both,
> > > >it can differentiate the authentication process by using
> different
> > > >client identifiers in each. Therefore PAA can demultiplex the
> > > >authentication request to the right backend.
> > > >
> > > >So, running PANA twice between the PaC and the same PAA maybe one
> > > >approach. Each time PaC can use a different set of
> credentials. If the
> > > >same credentials are used, then we need something else
> in the process
> > > >to indicate which one is for NAP authentication vs for ISP
> > > >authentication.
> > > >
> > > >When two different set of credentials are used, if PaC
> uses the same
> > > >DI, this might be an issue. Normally they would appear
> as two separate
> > > >clients to the PAA, but since the network is aware of this
> > > >dual-authentication
> > > >scheme, and the requests are coming from the same
> circuit, maybe this
> > > >can be handled. And than, how will these DIs be used with service
> > > >provisioning, after each authentication? Is EP still co-located
> > > >with BAS here? How should the NAP authentication update
> EP, and ISP
> > > >authentication update EP? These are general questions
> about the model
> > > >you are describing..
> > > >
> > > >
> > > >alper
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >----- Original Message -----
> > > >From: MORAND Lionel FTRD/DAC/ISS
> > > >To: [email-masked] ; Yoshihiro Ohba ;
> > > >[email-masked]
> > > >; Alper E. YEGIN
> > > >Sent: Monday, December 09, 2002 5:59 AM
> > > >Subject: About the NAP/ISP distinction in the
> usage-scenarios draft...
> > > >
> > > >
> > > >Hi folks,
> > > >
> > > >In the current version of the Usage-Scenario draft, in
> the section 3:
> > > >Problem Statement, the distinction between NAP (Network Acces
> > > >Provider) and
> > > >ISP (Internet Service Provider) is pointing out.
> > > >
> > > >[...An important aspect of an authentication protocol is
> the ability to
> > > >provide dynamic service provider selection to the clients.
> > > >Regardless of
> > > >their network access provider (NAP), clients should be able to
> > > >select an
> > > >Internet access provider (ISP) of their choice. This is
> > > >usually achieved by
> > > >clients presenting an identifier which carries domain
> > > >information during the
> > > >authentication process. ]
> > > >
> > > >This distinction is particularly true in the case of DSL
> > > >networks where NAP
> > > >and ISP are often two different players. Besides traditional
> > > >"package" offer
> > > >(access + Internet provided by the ISP), NAP are able to
> > > >provide broadband
> > > >access services directly to the user, regardless of the ISP
> > > >selected by the
> > > >user. Moreover, different access network configurations may be
> > > >provide to an
> > > >xDSL client, based on the access service subscribed to the
> > > >NAP. We could
> > > >also imagine the provision of some local services in the
> > > >short/medium term.
> > > >
> > > >In order to provide such a "customized" service, the NAP needs to
> > > >identify/authenticate the user that logs on to the
> access network. This
> > > >authentication is independent from the authentication achieved
> > > >by the ISP
> > > >and so not necessarily based on the same user credentials.
> > > >This induces a
> > > >requirement for two levels of authentication: one at the NAP
> > > >level, one at
> > > >the ISP level. I think that this requirement is not only
> > > >restricted to xDSL
> > > >network and be generalized on the contrary.
> > > >
> > > >For the time being, if PPP is used to carry user
> information for ISP
> > > >authentication, NAP identification is mainly based on
> > > >information on the
> > > >physical link used for the connection (phone line number, ATM
> > > >link, etc.)
> > > >and not according to the user using the connection. So it is
> > > >not possible to
> > > >distinguish two consecutive users using the same link
> and the network
> > > >configuration is only based on the service subscribed for the
> > > >access link.
> > > >
> > > >and now I wonder:
> > > >How the PANA protocol could fulfil such a requirement on two
> > > >authentication
> > > >levels (NAP, ISP)?
> > > >What would be the consequences on the general PANA requirements?
> > > >Would it be useful to include/precise this scenario be
> in the current
> > > >usage-scenarios draft?
> > > >Any comment/reaction from the mailing list?
> > > >
> > > >Lionel.
> > > >
> > > >
> > >
> >
> >
>
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 9 Jan 2003 12:55:51 -0500

> When PaC utilizes multiple ISPs, the auth. happens when PaC starts to access the ISP's network.

The usage scenario team actually considered that scenario before
submitting the current version.  But we concluded we should not
describe it due to the difficulty of supporting multihomed
single-interface hosts.  I attach related email discussion in IPv6
WG (sorry for long attachment).

Yoshihiro Ohba

Subject: multihomed host
To: [email-masked], [email-masked]
Date: Wed, 9 Oct 2002 15:28:41 -0400

Hi,

I have one question about multihomed host.

In the multi6 WG charter, there is the following definition 
for multihomed "site":

  A multihomed site is a site that has more than one connection to the
  public internet with those connections through either the same or
  different ISPs.  Sites choose to multihome for several reasons,
  especially to improve fault tolerence, perform load balancing, etc.

Is there any definition for multihomed "host"?  

Of cource, a definition would be quickly made by just replacing a
word "site" in the above definition with "host", but please let me
know if there is other definition.

Regards,
Yoshihiro Ohba

Subject: multihomed host
From: Yoshihiro Ohba <[email-masked]>
To: [email-masked], [email-masked]
Date: Wed, 9 Oct 2002 15:28:41 -0400

Hi,

I have one question about multihomed host.

In the multi6 WG charter, there is the following definition 
for multihomed "site":

  A multihomed site is a site that has more than one connection to the
  public internet with those connections through either the same or
  different ISPs.  Sites choose to multihome for several reasons,
  especially to improve fault tolerence, perform load balancing, etc.

Is there any definition for multihomed "host"?  

Of cource, a definition would be quickly made by just replacing a
word "site" in the above definition with "host", but please let me
know if there is other definition.

Regards,
Yoshihiro Ohba

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

Subject: Re: multihomed host
From: Margaret Wasserman <[email-masked]>
To: Yoshihiro Ohba <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 09 Oct 2002 15:42:47 -0400

>
>
>Is there any definition for multihomed "host"?

I don't know if there is an official definition, but I
have usually heard the term "multihomed host" used to
refer to multi-interface systems that do not function
as routers (i.e. they don't forward packets).

Margaret

Subject: Re: multihomed host
From: Yoshihiro Ohba <[email-masked]>
To: Margaret Wasserman <[email-masked]>
Cc: Yoshihiro Ohba <[email-masked]>, [email-masked], [email-masked]
Date: Wed, 9 Oct 2002 16:09:20 -0400

Thanks for your quick response.

There may be some scenario in which a single-interface host is connected
to multiple ISPs on the same link, which seems to be not covered in
the usual definition for "multihomed host".

I don't know what to call the model, but is such a model already 
common?  Or is there any ongoing work on this model?

On Wed, Oct 09, 2002 at 03:42:47PM -0400, Margaret Wasserman wrote:
> 
> >
> >
> >Is there any definition for multihomed "host"?
> 
> I don't know if there is an official definition, but I
> have usually heard the term "multihomed host" used to
> refer to multi-interface systems that do not function
> as routers (i.e. they don't forward packets).
> 
> Margaret
> 

Thanks,

Yoshihiro Ohba

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

Subject: Re: multihomed host
From: Bill Sommerfeld <[email-masked]>
To: Margaret Wasserman <[email-masked]>
Cc: Yoshihiro Ohba <[email-masked]>, [email-masked], [email-masked]
Date: Wed, 09 Oct 2002 16:31:28 -0400

> I don't know if there is an official definition, but I
> have usually heard the term "multihomed host" used to
> refer to multi-interface systems that do not function
> as routers (i.e. they don't forward packets).

For what it's worth, I've occasionally heard the term used in an
application-layer context to refer to hosts having multiple IP
addresses rather than/in addition to multiple interfaces. 

						- Bill

Subject: Re: multihomed host
From: William Waites <[email-masked]>
To: Bill Sommerfeld <[email-masked]>
Cc: Margaret Wasserman <[email-masked]>, Yoshihiro Ohba <[email-masked]>, [email-masked], [email-masked]
Date: 10 Oct 2002 14:44:54 -0400

>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:

    Bill> For what  it's worth, I've occasionally heard  the term used
    Bill> in  an application-layer  context to  refer to  hosts having
    Bill> multiple  IP addresses rather  than/in addition  to multiple
    Bill> interfaces.

This  just  looks like  the  degenerate  case  -- multiple  addresses,
multiple  interfaces,  except that  each  of  the multiple  interfaces
happen to  be the  same. It seems  to me  that the network  layer code
should treat both cases identically. Does this make sense?

-w
-- 
William Waites <[email-masked]>
Idiosyntactix Research Laboratories	Any sufficiently advanced technology
http://www.irl.styx.org			is indistinguishable from a rigged demo.

Subject: Re: multihomed host
From: Erik Nordmark <[email-masked]>
To: William Waites <[email-masked]>
Cc: Bill Sommerfeld <[email-masked]>, Margaret Wasserman <[email-masked]>, Yoshihiro Ohba <[email-masked]>, [email-masked], [email-masked]
Date: Fri, 11 Oct 2002 15:15:30 +0200 (CEST)

> This  just  looks like  the  degenerate  case  -- multiple  addresses,
> multiple  interfaces,  except that  each  of  the multiple  interfaces
> happen to  be the  same. It seems  to me  that the network  layer code
> should treat both cases identically. Does this make sense?

There are some important differences when it comes to the relationship
between IP source address and routes that are used.

draft-ietf-ipv6-default-addr-select-09.txt
specifies that the candidate source address are related to the
interface on which a packet is sent.

Hence there is a difference  between 
case 1:
	Host with one interface, two routers, two global addresses with
	different prefixes (whether one router advertises each addrconf prefix
	or both routers advertise both prefixes).

	In this case the candidate source address will be both global
	addresses, and the other rules in the source address selection
	will determine which source address is used.

	Note that there is no relationship between the source address selected
	and which (default) router is used for sending packets.

case 2:
	Host with two interface, one router on each interface, one global
	address being configured on each interface with different prefixes
	(each router advertises a single addrconf prefix)

	In this case the candidate source address set will be coupled
	to the (default) route used to send the packet, since there
	are two interfaces.

In both cases there are issues of what happens when e.g. one of the routers
fail, which have to do with not only how the host behaves but also how
routing works beyond the first hop routers.

  Erik

Subject: RE: multihomed host
From: "Michel Py" <[email-masked]>
To: <[email-masked]>, "Margaret Wasserman" <[email-masked]>
Cc: "Yoshihiro Ohba" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 9 Oct 2002 15:21:34 -0700

> Yoshihiro Ohba wrote:
> I don't know if there is an official definition, but I
> have usually heard the term "multihomed host" used to
> refer to multi-interface systems that do not function
> as routers (i.e. they don't forward packets).

Here is my reading of this:

1. Multi-interface host:
> Margaret Wasserman wrote:
> I don't know if there is an official definition, but I
> have usually heard the term "multihomed host" used to
> refer to multi-interface systems that do not function
> as routers (i.e. they don't forward packets).

I agree with Margaret. A host that has multiple interfaces connected to
multiple subnets *is* a multihomed host, but...

2. A host that has multiple interfaces with addresses in the same subnet
(either to increase throughput or to provide redundancy) is *not* a
multihomed host.

3. Single interface, multiple address host:
> Bill Sommerfeld wrote:
> For what it's worth, I've occasionally heard the
> term used in an application-layer context to refer
> to hosts having multiple IP addresses rather than/in
> addition to multiple interfaces.

For v4, I agree with Bill *if* the multiple addresses belong to
different subnets.

For v6, this is blurry. Would you call multihomed a host that has both a
link-local and a regular unicast address on the same interface? I don't
think so.

On the other hand,
> Yoshihiro Ohba wrote:
> There may be some scenario in which a single-interface
> host is connected to multiple ISPs on the same link, which
> seems to be not covered in the usual definition for
> "multihomed host". I don't know what to call the model,
> but is such a model already common? Or is there any
> ongoing work on this model?

This is possible as of today; a host that has multiple PA addresses is
certainly considered a multihomed host. However, this alone is not a
multihoming solution.

4. A host that has a single address but is part of a multihomed site:
This would be the case for hosts belonging to a multihomed LIR, or the
case of hosts connecting to a MHAP network. I do not call these hosts
multihomed.

In other words: semantically speaking, the fact that the host is
connected to a multihomed router does not make the host itself
multihomed, IMHO.

Michel.

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

Subject: Re: multihomed host
From: Bill Sommerfeld <[email-masked]>
To: "Michel Py" <[email-masked]>
Cc: [email-masked], "Margaret Wasserman" <[email-masked]>, "Yoshihiro Ohba" <[email-masked]>, [email-masked], [email-masked]
Date: Wed, 09 Oct 2002 18:48:32 -0400

> For v4, I agree with Bill *if* the multiple addresses belong to
> different subnets.
> 
> For v6, this is blurry. Would you call multihomed a host that has both a
> link-local and a regular unicast address on the same interface? I don't
> think so.

>From the point of view of what applications need to do, it's safest to
assume that all V6 hosts are multiaddressed.

						- Bill

Subject: Re: multihomed host
From: Yoshihiro Ohba <[email-masked]>
To: Michel Py <[email-masked]>
Cc: [email-masked], Margaret Wasserman <[email-masked]>, Yoshihiro Ohba <[email-masked]>, [email-masked], [email-masked]
Date: Wed, 9 Oct 2002 19:20:56 -0400

Thank you all for helping me understand.

I have additional question below.

On Wed, Oct 09, 2002 at 03:21:34PM -0700, Michel Py wrote:
> On the other hand,
> > Yoshihiro Ohba wrote:
> > There may be some scenario in which a single-interface
> > host is connected to multiple ISPs on the same link, which
> > seems to be not covered in the usual definition for
> > "multihomed host". I don't know what to call the model,
> > but is such a model already common? Or is there any
> > ongoing work on this model?
> 
> This is possible as of today; a host that has multiple PA addresses is
> certainly considered a multihomed host. However, this alone is not a
> multihoming solution.
> 

What additional things need to be considered for this usage to become
a multihoming solution?

Yoshihiro Ohba

Subject: Re: multihomed host
From: Iljitsch van Beijnum <[email-masked]>
To: Yoshihiro Ohba <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Thu, 10 Oct 2002 09:02:34 +0200 (CEST)

On Wed, 9 Oct 2002, Yoshihiro Ohba wrote:

> > This is possible as of today; a host that has multiple PA addresses is
> > certainly considered a multihomed host. However, this alone is not a
> > multihoming solution.

> What additional things need to be considered for this usage to become
> a multihoming solution?

A good multihoming solution keeps working if there are failures. So the
applications must be smart enough to try all the addresses rather than
just one. Telnet and FTP do this, WWW clients typically don't.
Unfortunately, this must be done at the remote end and not on the
multi(homed|addressed) host itself.

When there is a session, and the path over one ISP becomes unavailable,
the multihomed host must switch to the path over the other ISP. There are
many problems with this. First of all, the failure must be detected. Then
the host can reroute outgoing packets. But if the host still uses the same
source address (from the address space from the failed ISP), it is likely
the packets won't be accepted by the alternate ISP because the source
addresses are "spoofed". And even if they are, the communications partner
keeps sending packets back to th source address tied to the first ISP,
which isn't reachable any more.

One solution for the address problem would be the adoption of new or
improved transport protocols that can handle this. There have been
experiments with modifications to TCP to support this, and the new SCTP
protocol can also handle this. However, modifying all transport protocols
might be problematic.

Another solution is tunnelling/aliasing the packet to hide the original
address while the packet is rerouted over the alternative path. The
destination host or a box very close to the destination host strips of the
tunnel header or replaces the original address so TCP and other transport
protocols don't see the change in address.

Some of us are working on this stuff on a non-IETF mailinglist. The latest
idea is to come up with a common tunnelling/aliasing framework so
different solutions in this area may interoperate.

Subject: Re: multihomed host
From: Yoshihiro Ohba <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>, Michel Py <[email-masked]>
Cc: Yoshihiro Ohba <[email-masked]>, [email-masked], [email-masked], [email-masked], Margaret Wasserman <[email-masked]>
Date: Thu, 10 Oct 2002 11:20:35 -0400

Thanks Iljitsch for detailed answer and Michel for the pointer.

Actually, I'm working in the PANA WG and viewing this kind of
multihomed host scenario from network access authentication
perspective, and wondering whether the PANA WG needs to consider this
scenario for now.  (My impression is that there is a lot of work to
consider before considering network access authentication)

Yoshihiro Ohba

On Thu, Oct 10, 2002 at 09:02:34AM +0200, Iljitsch van Beijnum wrote:
> On Wed, 9 Oct 2002, Yoshihiro Ohba wrote:
> 
> > > This is possible as of today; a host that has multiple PA addresses is
> > > certainly considered a multihomed host. However, this alone is not a
> > > multihoming solution.
> 
> > What additional things need to be considered for this usage to become
> > a multihoming solution?
> 
> A good multihoming solution keeps working if there are failures. So the
> applications must be smart enough to try all the addresses rather than
> just one. Telnet and FTP do this, WWW clients typically don't.
> Unfortunately, this must be done at the remote end and not on the
> multi(homed|addressed) host itself.
> 
> When there is a session, and the path over one ISP becomes unavailable,
> the multihomed host must switch to the path over the other ISP. There are
> many problems with this. First of all, the failure must be detected. Then
> the host can reroute outgoing packets. But if the host still uses the same
> source address (from the address space from the failed ISP), it is likely
> the packets won't be accepted by the alternate ISP because the source
> addresses are "spoofed". And even if they are, the communications partner
> keeps sending packets back to th source address tied to the first ISP,
> which isn't reachable any more.
> 
> One solution for the address problem would be the adoption of new or
> improved transport protocols that can handle this. There have been
> experiments with modifications to TCP to support this, and the new SCTP
> protocol can also handle this. However, modifying all transport protocols
> might be problematic.
> 
> Another solution is tunnelling/aliasing the packet to hide the original
> address while the packet is rerouted over the alternative path. The
> destination host or a box very close to the destination host strips of the
> tunnel header or replaces the original address so TCP and other transport
> protocols don't see the change in address.
> 
> Some of us are working on this stuff on a non-IETF mailinglist. The latest
> idea is to come up with a common tunnelling/aliasing framework so
> different solutions in this area may interoperate.
> 
> 

On Wed, Oct 09, 2002 at 11:11:09PM -0700, Michel Py wrote:
> >>> Yoshihiro Ohba wrote:
> >>> There may be some scenario in which a single-interface
> >>> host is connected to multiple ISPs on the same link, which
> >>> seems to be not covered in the usual definition for
> >>> "multihomed host". I don't know what to call the model,
> >>> but is such a model already common? Or is there any
> >>> ongoing work on this model?
>  
> >> Michel Py wrote:
> >> This is possible as of today; a host that has multiple PA
> >> addresses is certainly considered a multihomed host.
> >> However, this alone is not a multihoming solution.
> 
> > What additional things need to be considered for this
> > usage to become a multihoming solution?
> 
> There is no simple answer to this question. Here is one approach:
> http://arneill-py.sacramento.ca.us/ipv6mh/draft-bagnulo-mhExtHdr-00.txt
> 
> Michel.
> 
> 

Subject: RE: multihomed host
From: "Michel Py" <[email-masked]>
To: <[email-masked]>
Cc: "Margaret Wasserman" <[email-masked]>, "Yoshihiro Ohba" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 9 Oct 2002 15:55:55 -0700

> Bill Sommerfeld wrote:
> From the point of view of what applications need to do,
> it's safest to assume that all V6 hosts are multiaddressed.

Strongly agree. Although multiaddressed does not necessarily mean
multihomed, it is likely that part of the multihoming solution is
multiadressed hosts.

Michel.

Subject: RE: multihomed host
From: "Michel Py" <[email-masked]>
To: <[email-masked]>
Cc: "Margaret Wasserman" <[email-masked]>, "Yoshihiro Ohba" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 9 Oct 2002 15:55:55 -0700

> Bill Sommerfeld wrote:
> From the point of view of what applications need to do,
> it's safest to assume that all V6 hosts are multiaddressed.

Strongly agree. Although multiaddressed does not necessarily mean
multihomed, it is likely that part of the multihoming solution is
multiadressed hosts.

Michel.

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

Subject: RE: multihomed host
From: "Michel Py" <[email-masked]>
To: "Yoshihiro Ohba" <[email-masked]>
Cc: <[email-masked]>, "Margaret Wasserman" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Wed, 9 Oct 2002 23:11:09 -0700

>>> Yoshihiro Ohba wrote:
>>> There may be some scenario in which a single-interface
>>> host is connected to multiple ISPs on the same link, which
>>> seems to be not covered in the usual definition for
>>> "multihomed host". I don't know what to call the model,
>>> but is such a model already common? Or is there any
>>> ongoing work on this model?
 
>> Michel Py wrote:
>> This is possible as of today; a host that has multiple PA
>> addresses is certainly considered a multihomed host.
>> However, this alone is not a multihoming solution.

> What additional things need to be considered for this
> usage to become a multihoming solution?

There is no simple answer to this question. Here is one approach:
http://arneill-py.sacramento.ca.us/ipv6mh/draft-bagnulo-mhExtHdr-00.txt

Michel.

Subject: RE: multihomed host
From: "Hesham Soliman (EAB)" <[email-masked]>
To: "'William Waites'" <[email-masked]>, Bill Sommerfeld <[email-masked]>
Cc: Margaret Wasserman <[email-masked]>, Yoshihiro Ohba <[email-masked]>, [email-masked], [email-masked]
Date: Fri, 11 Oct 2002 00:39:09 +0200

  > >>> "Bill" == Bill Sommerfeld <[email-masked]> writes:
  > 
  >     Bill> For what  it's worth, I've occasionally heard  
  > the term used
  >     Bill> in  an application-layer  context to  refer to  
  > hosts having
  >     Bill> multiple  IP addresses rather  than/in addition  
  > to multiple
  >     Bill> interfaces.
  > 
  > This  just  looks like  the  degenerate  case  -- multiple  
  > addresses,
  > multiple  interfaces,  except that  each  of  the multiple  
  > interfaces
  > happen to  be the  same. It seems  to me  that the network  
  > layer code
  > should treat both cases identically. Does this make sense?

=> I don't think so. There is a difference in existing 
standards (2461) and implementations between the 2 cases. 
A multiaddressed node with a single interface assumes 
that any address can be used as a source address with any
default router. This is clearly not a good assumption 
for multi-interfaced (multihomed) nodes

Hesham