Subject: Fwd: I-D ACTION:draft-bagnulo-ipv6-rfc3484-update-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 2 Dec 2005 12:01:57 +0100

Hi,

we would like to submit this draft for the consideration of the IPv6 wg.

This draft identifies limitations in RFC3484 in multihomed  
configurations.

The conclusion is that some changes are needed to properly support such  
cases.

The goal of the draft is to foster discussion and try to determine if  
we need to generate a rfc3484bis to overcome the identified problems

Comments?

Regards, marcelo

Inicio mensaje reenviado:

> De: [email-masked]
> Fecha: 1 de diciembre de 2005 21:50:02 GMT+01:00
> Para: [email-masked]
> Asunto: I-D ACTION:draft-bagnulo-ipv6-rfc3484-update-00.txt
> Responder a: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
>
> 	Title		: Updating RFC 3484 for multihoming support
> 	Author(s)	: M. Bagnulo
> 	Filename	: draft-bagnulo-ipv6-rfc3484-update-00.txt
> 	Pages		: 12
> 	Date		: 2005-12-1
> 	
>    This note describes the limitations of RFC 3484 in multihomed
>    environments and proposes possible updates to the default address
>    selection mechanisms in order to cope with the identified
>    limitations.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bagnulo-ipv6-rfc3484-update 
> -00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of  
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the  
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-bagnulo-ipv6-rfc3484-update-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-bagnulo-ipv6-rfc3484-update-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Mon, 05 Dec 2005 10:46:55 +0100

In your previous mail you wrote:

   Comments?
   
=> I have some comments:
 - if the border router for X to A knows the outage it can deprecate
   the A prefix and propagate the information. Note this idea was
   described many time but as far as I know is *not* implemented
   (if such basic idea is not supported I am afraid we'll get
   no help from routers).
   Perhaps the document should say something about this, for instance
   explaining some outages can't be detected so easily...

 - the document should address as soon as possible the orders between
   destination and source addresses, i.e., it is S1-D1, S2-D1, S1-D2,
   S2-D2 or S1-D1, S1-D2, S2-D1, S2-D2?

 - note that many applications which specify source addresses in
   fact simply use source addresses returned by the selection
   mechanism (connect() then getsockname())...

 - the Rule 0 is not enough accurate: it assumes some state is kept
   (what state? how? lifetime? etc). IMHO the document has to
   provide guidelines!

 - in the Rule 0 the term "unreachable" is not the right one, IMHO
   it is more "not working for D"?

 - it is not true that RFC 3484 provides an ordered list of destination
   address, it only orders the list provided by DNS & co. BTW it should
   be useful to know when the tail of a list contains unusable
   addresses or to remove them.

 - IMHO it should be fine to get a support for address pairs because
   it is needed for any scheme which replaces the last "longest
   prefix match" rules by a better thing. I think about NAROS but
   there should be many similar ideas.

 - in 3.2.1 there are other transport protocols than TCP and UDP.
   I prefer connection oriented and connection less.

 - in 3.2.2 the amount of tried source addresses has to be controlled.
   IMHO a better mechanism for both TCP and UDP is a new setsockopt()
   which the N first elements of the source address list. The only
   issue is this hint can be obsolete when the list changes but
   when you look at the rules you can see they should give a stable
   ordering. Of course, it can be used to get the source address list
   for a destination...

Thanks

[email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 6 Dec 2005 20:49:50 +0100

Hi Francis,

thanks for your feedback

comments below...

>    explaining some outages can't be detected so easily...

i agree this is a useful tool for multihomed environments (i have 
included it in draft-bagnulo-shim6-addr-selection-00.txt) and i agree 
that this should be detailed in a document related to initiating 
communications in multihomed environments
However, i am not sure if this would belong to a new version of RFC3484 
which is the goal of this document...

>    S2-D2 or S1-D1, S1-D2, S2-D1, S2-D2?

right, this would be the optimal approach, since it would provide an 
order of address pairs (as opposed to an order of destiantion addresses 
and for each deatiantion address, an ordered list of source addresses) 
but the difficulty with this is that current functions do not return 
address pairs, but destination addresses and source addresses 
separately. I guess that one option would be to define new function 
calls that return list of src,dst address pairs, but this wouldn't be 
compatible with current apps, since they don't use these to-be-defined 
functions
I guess that an option would be to define the two approaches, on one 
hand the approach to define the list of dest addresses and for each 
dest address an ordered list of source addresses and the other approach 
(for updated apps) the returns an ordered list of src,dst address pairs

>    mechanism (connect() then getsockname())...

right
the idea would be that the src addresses returned are ordered. The 
difficulty is that this fucntion call does not refers to any specific 
destiantion address and providing an order independent of the 
destiantion is of little use imho
so, the option would be to define a new function call that returns an 
ordered list of source address available for a particular destiantion 
address

>    (what state? how? lifetime? etc). IMHO the document has to

agree
in draft-bagnulo-shim6-addr-selection-00.txt there is a proposal to use 
information in incoming packets as hints to determine which address 
pairs are working. This information is cached and can be used to 
determine if an address pair is working

>    it is more "not working for D"?

agree
an alternative would be to talk about working/non-working address pairs

>    address, it only orders the list provided by DNS & co.

I am not sure i understand the difference here...

the rationale behind this is that a host wants to communicate with a 
given host identified by a fqdn
It then obtains the list of destiantion addresses for that fqdn from 
the dns
then rfc3484 orders the list provided by the dns
so, i would say that rfc3484 returns an ordered list of destiantion 
addresses...

what is the aspect that i am missing here?

>  BTW it should

yes this could be an option
otoh, an address pair working/non-working status may change over time 
(and quite fast)
so, possibly it may worth trying with address pairs that were not 
working some minutes ago, if there are no other options (i.e. other 
options have been tried later and they are not working)

so including the addresses that were not working at the end of the list 
may be of some use

>    there should be many similar ideas.

i am not sure i understand this point...

>    I prefer connection oriented and connection less.

agree

>    which the N first elements of the source address list.

in this case the application would be:
- first obtaining the src address list for a given destiantion with a 
new call setting, and then
- it would be setting the list of source addresses to be tried by 
TCP/UDP using this new option, passing the list (or part of) obtained 
in the previous point
right?

This is an interesting middle ground option indeed, where the 
application does not select a single address (as with bind()) nor it 
leaves the src address unspecified (which is the actual scenario 
considered in section 3.2.2)

regards, marcelo

> The only

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Dec 2005 03:09:39 +0100

=> to be complete the document in its introduction should explain
there are some cases without solutions so should list the possible
solutions to find cases where none applies. This is the way I'll
quickly explain the deprectation of prefixes from broken ISPs.

=> note I didn't ask for a solution but for the set out of the problem
(it seems I was not clear enough, I apologize).

=> this can be easily done by a middleware (aka bump in the API),
including the very special one named the shim6 layer...

=> I don't believe in updated apps: we have to support this idea but
we have more to never rely on it!

   right
   destiantion address

=> in the common mechanism I describe the destination is clearly taken
into account (it is the argument of connect()).

   and providing an order independent of the 
   destiantion is of little use imho
   so, the option would be to define a new function call that returns an 
   ordered list of source address available for a particular destiantion 
   address
   
=> a function or a simpler mechanism.

   agree
   
=> so you have to cite this document and even to explain how to use
its ideas outside the shim6 context.

   agree
   
=> you can't talk about an address pair in a function about an argument:
you have to find a better wording.

   
=> it does not create the destination address list. BTW it is just
a wording issue.

   
=> a function is not defined by its return value but by its return value
in function of its arguments (this is why it is named "function").
Sorry but I began in functional programming and I do important
differences for things which can be considered as details, like
"(f x) y" is not the same than "f (x,y)" cf a previous comment.

   
   
=> a good alternative is to provide a reliability judgement so
a clever implementation can adapt its strategy in looking for
a working pair (I think about a sorting on address pairs).

   
=> look at draft-de-launois-multi6-naros-00.txt or read Cedric's PhD
document. To apply this kind of ideas you both have to replace
last rules and to give address pairs to the application.
So to be able to handle address pairs is an important goal in a
larger scope than this I-D.

=> no, I don't see why this step is useful. Even the src address list
length is not important.

=> you didn't understand my idea. In place to handle in the application
the source address list per destination you just specify the destination
and the number of the item of the source address list.
Of course you can get by connect() then getsockname() the source
address but you don't need to do this.

=> the idea is to replace the bind() by a simpler setsockopt()
with a counter.

Thanks

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Dec 2005 09:27:43 +0100

A couple of minor comments.

1. I wonder if it would be better to use the shim6 terminology "ULP"
(upper layer protocol) instead of "application."  At least, I suggest
referring to it.

2. In section 3.2, I think you also need to say something about
SCTP. I presume that the interaction between 3484bis and SCTP will
be quite complex.

    Brian

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 21 Dec 2005 18:20:44 +0900

Hi all,

Firstly, according to a minutes of the last shim6 meeting,
http://www3.ietf.org/proceedings/05nov/minutes/shim6.html
this issue of revising RFC3484 was passed to AD.
I want to know if this proposal was arranged by AD.

IMHO, these new functions look very effective and desirable
to solve address selection problems. At the same time,
however, inserting these rules into RFC3484 seems to involve
such a tough modification to protocol stack.

I suppose we should separate some already-raised issues about
updating RFC3484 from these radical issues.

-- 
Arifumi Matsumoto <[email-masked]>