Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt

From: [email-masked]
Date: Mon, 07 May 2007 18:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title		: Extension to the Simple Traversal Underneath NAT (STUN) Relay Usage for IPv4/IPv6 Transition
	Author(s)	: G. Camarillo, O. Novo
	Filename	: draft-ietf-behave-turn-ipv6-02.txt
	Pages		: 8
	Date		: 2007-5-7
	
This document defines the REQUESTED-ADDRESS-TYPE attribute for the
   Simple Traversal Underneath NAT (STUN) Relay Usage, which allows a
   client to explicitly request the address type the STUN relay server
   will allocate (e.g., an IPv4-only node may request the STUN relay
   server to allocate an IPv6 address).  Additionally, this document
   also defines a new error response code with the value 440 (Address
   Family not Supported).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-ipv6-02.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-ietf-behave-turn-ipv6-02.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-ietf-behave-turn-ipv6-02.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.
_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 9 May 2007 16:21:16 +0300

Hello,

>    also defines a new error response code with the value 440 (Address

A few notes:

1/ Format for the family parameter within the attribute is not consistent with 
that used in STUN (XOR-)MAPPED-ADDRESS et al, where it consists of a single 
byte. Is there any reason for this?

2/ In my humble opinion, the address family numbers should simply refer to the 
base STUN spec instead of redefining the same values... so we do not need to 
duplicate effort if we ever were to define new families (HIP?).

3/ I might have missed it, but what is the request address type is absent? 
Should the default be "always IPv4", or "protocol through which the server 
received the Allocate Request" ? I would assume "always IPv4" is better, 
consistent with RFC3489bis insistance that there might be IPv4-to-IPv6 or 
IPv6-to-IPv4 translation middleboxes.

4/ As I already pointed out earlier, the current TURN-IPv6 model does not 
quite seem to fit with RFC3484, ICE and/or ANAT. I'd rather expect the server 
returns a list of possible addresses, one per RFC3484 label, as far as it has 
such an address.

Regards,

-- 
Rémi Denis-Courmont

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 May 2007 21:17:20 -0700

...
> 4/ As I already pointed out earlier, the current TURN-IPv6 
> model does not quite seem to fit with RFC3484, ICE and/or ANAT. 
> I'd rather expect the server 
> returns a list of possible addresses, one per RFC3484 label, 
> as far as it has such an address.

I expect this could that be accomplished by returning multiple RELAY-ADDRESS
attributes, yes?

I don't the need to return the TURN server's RFC3484 label itself, though --
is that necessary?

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 11 May 2007 10:45:58 +0300

On Friday 11 May 2007 07:17:20 ext Dan Wing wrote:
> I expect this could that be accomplished by returning multiple
> RELAY-ADDRESS attributes, yes?

I have seen several STUN implementations that can only handle one attribute of 
any given type per message, but otherwise that should work.

> I don't the need to return the TURN server's RFC3484 label itself, though
> -- is that necessary?

No, of course not. Labels depend on the local system configuration anyway, 
that was only a hint that, in view of RFC3484, it would be better to not only 
give a native IPv6 address, but also (if one is available), say a 6to4 
address, an ULA, and so on...

-- 
Rémi Denis-Courmont

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 May 2007 11:54:10 -0700

> I have seen several STUN implementations that can only handle 
> one attribute of any given type per message, but otherwise 
> that should work.

We can restrict the TURN server's retuning of multiple 
RELAY-ADDRESSes so they are only returned if the STUN client 
included the Magic Cookie value (which indicates the STUN client 
is rfc3489bis compliant, rather than rfc3489 compliant).

> > I don't the need to return the TURN server's RFC3484 label 
> > itself, though -- is that necessary?
> 
> No, of course not. Labels depend on the local system 
> configuration anyway, that was only a hint that, in view of 
> RFC3484, it would be better to not only give a native IPv6 
> address, but also (if one is available), say a 6to4 

But could an ICE endpoint find such information useful in prioritizing or
preferring different addresses?

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 14 May 2007 09:17:06 +0300

> is rfc3489bis compliant, rather than rfc3489 compliant).

Well, I meant some STUN parsers, regardless of RFC3489 or RFC3489bis. If we go 
that route, I believe RFC3489bis will need some more explicit note that an 
implementation must be able to handle duplicate attribute types.

> preferring different addresses?

One obvious benefit to this approach compared to the REQUEST-ADDRESS-TYPE 
approach is that it avoids duplicating the TURN state machine (and RTT) on 
both the TURN client and the TURN server if the client is dual-stack.

The usefulness of getting both an IPv4 and a IPv6 address looks obvious: ANAT 
needs that, and ICE-to-replace-ANAT will need it too. As for including a 6to4 
or Teredo address in addition to a native IPv6, it avoids "quadrangular" 
routing such as this:

TURN client
  exchanges packets over NATed IPv4 with
TURN server, which
  exchanges packets over native IPv6 with
6to4 relay, which
  exchanges packets over proto-41 with
Peer

and does that instead:

TURN client
  exchanges packets over NATed IPv4 with
TURN server, which servers as its own 6to4 relay
  exchanges packets over proto-41 with
Peer

But maybe I am too optimistic as too how well ICE will pair candidates. Indeed 
IETF hasn't defined an API for RFC3484 :(

Regards,

-- 
Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 16 May 2007 08:59:14 +0300

On Tuesday 15 May 2007 17:17:05 ext Oscar Novo (JO/LMF) wrote:
> 1/ Format for the family parameter within the attribute is not consistent
> with that used in STUN (XOR-)MAPPED-ADDRESS et al, where it consists of a
> single byte. Is there any reason for this?
>
> [ON] We can change the family parameter to a single byte to be consistent
> with the MAPPED-ADDRESS.
>
> 2/ In my humble opinion, the address family numbers should simply refer to
> the base STUN spec instead of redefining the same values... so we do not
> need to duplicate effort if we ever were to define new families (HIP?).
>
> [ON] STUN spec does not define any number for IPv6. It only defines the
> number for IPv4.

From draft-ietf-behave-rfc3489bis-06 §11.1:

   The address family can take on the following values:

   0x01:IPv4
   0x02:IPv6

I assume TURN-IPv6 depends on rfc3489bis due to depending on STUN Relay 
Usage/TURN.

> [ON] This draft defines a new attribute for STUN. If that attribute is
> absented you should follow the STUN spec and assume always IPv4.

The same RFC3489bis section says:

   It is possible for an IPv4 host to receive a MAPPED-ADDRESS
   containing an IPv6 address, or for an IPv6 host to receive a MAPPED-
   ADDRESS containing an IPv4 address.  Clients MUST be prepared for
   this case.

So this does not seem all that obvious to me. I however agree that it should 
be IPv4 by default EVEN IF the Allocate Request came through IPv6, to avoid 
problems with any kind of IPv4-to-IPv6 translation on the path.

-- 
Rémi Denis-Courmont

---

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Wed, 16 May 2007 09:11:36 +0200

Thanks for your feedback. My previous comments referred to STUN Relay Usage/TURN, not to 3489bis but you're right TURN-IPv6 should be consistent with 3489bis as well. I'll work in a new version of the draft and I will send it to the list in brief.

Oscar 

-----Original Message-----
From: Rémi Denis-Courmont [mailto:[email-masked]] 
Sent: 16. toukokuuta 2007 8:59
To: Oscar Novo (JO/LMF)
Cc: [email-masked]; Gonzalo Camarillo (JO/LMF)
Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt

On Tuesday 15 May 2007 17:17:05 ext Oscar Novo (JO/LMF) wrote:
> 1/ Format for the family parameter within the attribute is not 
> consistent with that used in STUN (XOR-)MAPPED-ADDRESS et al, where it 
> consists of a single byte. Is there any reason for this?
>
> [ON] We can change the family parameter to a single byte to be 
> consistent with the MAPPED-ADDRESS.
>
> 2/ In my humble opinion, the address family numbers should simply 
> refer to the base STUN spec instead of redefining the same values... 
> so we do not need to duplicate effort if we ever were to define new families (HIP?).
>
> [ON] STUN spec does not define any number for IPv6. It only defines 
> the number for IPv4.

   0x01:IPv4
   0x02:IPv6

I assume TURN-IPv6 depends on rfc3489bis due to depending on STUN Relay Usage/TURN.

> Should the default be "always IPv4", or "protocol through which the 
> server received the Allocate Request" ? I would assume "always IPv4" 
> is better, consistent with RFC3489bis insistance that there might be 
> IPv4-to-IPv6 or

So this does not seem all that obvious to me. I however agree that it should be IPv4 by default EVEN IF the Allocate Request came through IPv6, to avoid problems with any kind of IPv4-to-IPv6 translation on the path.

--
Rémi Denis-Courmont

---

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Tue, 15 May 2007 16:17:05 +0200

Hello Rémi,

Thanks for your comments, some more comments inline 

Cheers,

Oscar

-----Original Message-----
From: Rémi Denis-Courmont [mailto:[email-masked]] 
Sent: 9. toukokuuta 2007 16:21
To: [email-masked]; Gonzalo Camarillo (JO/LMF); Oscar Novo (JO/LMF)
Subject: Re: [BEHAVE] I-D ACTION:draft-ietf-behave-turn-ipv6-02.txt

	Hello,

A few notes:

1/ Format for the family parameter within the attribute is not consistent with that used in STUN (XOR-)MAPPED-ADDRESS et al, where it consists of a single byte. Is there any reason for this?

[ON] We can change the family parameter to a single byte to be consistent with the MAPPED-ADDRESS.

2/ In my humble opinion, the address family numbers should simply refer to the base STUN spec instead of redefining the same values... so we do not need to duplicate effort if we ever were to define new families (HIP?).

[ON] STUN spec does not define any number for IPv6. It only defines the number for IPv4.

3/ I might have missed it, but what is the request address type is absent? 
Should the default be "always IPv4", or "protocol through which the server received the Allocate Request" ? I would assume "always IPv4" is better, consistent with RFC3489bis insistance that there might be IPv4-to-IPv6 or
IPv6-to-IPv4 translation middleboxes.

[ON] This draft defines a new attribute for STUN. If that attribute is absented you should follow the STUN spec and assume always IPv4.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 22 May 2007 12:39:01 +0300

Hi,

> address, an ULA, and so on...

what are you thinking of regarding 6to4 addresses? Do you have a 
particular scenario in mind?

Regarding ULA addresses, they could be used between the relay and the 
remote endpoint if the relay and the remote endpoint happen to be in the 
same site, but... is it worthwhile adding the complexity needed to 
address this type of scenario taking into account that it works fine 
with the current solution?

If we decided to add support for relays to provide multiple IPv6 
addresses, ICE (i.e., STUN) checks would discover which ones work and 
which ones don't.

Cheers,

Gonzalo

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 22 May 2007 13:00:34 +0300

On Tuesday 22 May 2007 12:39:01 you wrote:
> Hi,
>
> > No, of course not. Labels depend on the local system configuration
> > anyway, that was only a hint that, in view of RFC3484, it would be better
> > to not only give a native IPv6 address, but also (if one is available),
> > say a 6to4 address, an ULA, and so on...
>

If the peer has 6to4 connectivity but no native IPv6, this would avoid using 
both a TURN *and* a separate 6to4 relay; same note applies to Teredo.

In 6to4 case, it would also ensure symmetric path of the IPv6-over-IPv4 
segment, as 6to4<->native often involves different 6to4 relays in each 
directions, while 6to4<->6to4 is always symmetric.

It is questionable whether this will be useful in practice (will any TURN 
relay have a 6to4 address anyway?).

One case that seems more obviously interesting to me is providing both an IPv4 
and an IPv6 address in the Allocate Response, which allows for efficient use 
of TURN with ICE in the usage scenario formerly addressed by ANAT (Note: IPv4 
is defined as its own label in RFC3484; though this would be a simpler and 
less generic). Without this I expect TURN clients would need to perform two 
TURN Allocate Request, and TURN server will get double the state and request 
processing work.

> addresses, ICE (i.e., STUN) checks would discover which ones work and

Yes, that's the point. I was referring to labels as an example because I doubt 
it would be useful to clutter the Allocate Response with different addresses 
with similar routing/topology properties. Of course, IPv6 addresses from 
different native prefixes could be provided if deemed potentially useful.

-- 
Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 25 May 2007 10:24:52 +0300

> addresses, ICE (i.e., STUN) checks would discover which ones work and

Hmm, I am now thinking there is another issue that I failed to think of in the 
first place, if we allow multiple mapped address for a single TURN 
allocation: how does the TURN server knows which mapped address to use when 
forwarding Send Indication?! :( Oops, sorry.

For the "simple" scenario that an allocation can have one IPv4 and one IPv6, 
it's fine (matching address family is sufficient), but if we allowed multiple 
IPv6 address, there might be an issue. Maybe it's better to stick to only one 
address per family at most?

Alternatives include ignoring this minor issue, or specifying the source 
address in Send Indication and the destination address in Data Indication. 
For those intimate with the BSD socket API or with RFC3542, this issue is 
equivalent to IP_PKTINFO and IP6_PKTINFO stuff.

-- 
Rémi Denis-Courmont

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 25 May 2007 11:22:09 +0300

Hi,

I have changed the subject to make discussions on this issue more explicit.

We could do as you suggest and include the source address in Send 
Indications and the destination address in Data Indications. I think it 
is better to be explicit, as opposed to having the relay use the 
destination or the source address of the data to decide which allocated 
address to use.

Additionally, we could define the new address family as follows:

0x02 - Global Unicast IPv6 address

If in the future we want to add support for, say, 6to4 addresses, we 
could define a new address type.

We also need to decide which model we want to support. At present, a 
client requests a set of address families from the server. Earlier in 
this thread, you seemed to want servers to provide clients with all the 
address families they support. I believe the former model would work 
fine as long as the client has a way to discover the capabilities of the 
server in order to figure out which address families are actually supported.

Comments?

Gonzalo

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 25 May 2007 12:20:42 +0300

> destination or the source address of the data to decide which allocated

True, thanks.

> could define a new address type.

This has pros and cons. A TURN client only need to know about IPv6 - not about 
6to4/Teredo/ULA - to be able to use a 6to4/Teredo/ULA mapped address. On the 
other hand, it would need to know about HIP if it were to use HIP (it's 
highly hypothetical that HIP will ever mix with TURN, but I cannot think of 
any other example).

The question really is whether it's worth the added complexity - if nobody 
ever deploys TURN relays with different types of IPv6 addresses, it's not 
much use. *I* am not working for a network gear vendor or an ISP, so I do not 
feel like taking a position on that thing.

> server in order to figure out which address families are actually

The simplest solution might be that the client puts all the address types it 
wants to use, and the server only replies with those that it supports, and 
return an error if it does not support any of these (a bit like TLS 
ciphersuite negociation, I believe).

I assume the client is only ever interested in the adress types that it knows. 
So the full list of types known to server is not much use. This also saves us 
one extra transaction (more spec work, more implementation and more 
round-trips).

Best regards,

-- 
Rémi Denis-Courmont

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 25 May 2007 14:10:39 +0300

Hi Remi,

it seems that we agree on defining the new address family as Global 
Unicast IPv6 Address, and including source address in Send Indications 
and the destination address in Data Indications, then.

We should also extend the 440 (Address Family not Supported) response so 
that it carries the identifiers of those addresses that are not 
supported (so that it is future proof, just in case there are more 
address types defined in the future).

Shall we go ahead edit the draft accordingly?

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 25 May 2007 14:19:25 +0300

Hi,

> one extra transaction (more spec work, more implementation and more

I was thinking of a capability discovery mechanism that clients could 
use to choose a relay. That is, they would not query the relay for its 
capabilities at session establishment time. Instead, this would be done 
at configuration time. For example, a user may prefer to configure its 
client with a relay that supports the allocation of both IPv6 and IPv4 
addresses, and not only IPv4.

Cheers,

Gonzalo

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 25 May 2007 15:55:23 +0300

> Shall we go ahead edit the draft accordingly?

That's fine with me, thanks.

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Tue, 29 May 2007 14:11:59 -0400

On 25-May-07, at 07:10 , Gonzalo Camarillo wrote:

> Unicast IPv6 Address, and including source address in Send  
> Indications and the destination address in Data Indications, then.

Sorry for jumping into this late.
I assume you are talking about adding a SourceAddress attribute to  
the Send Indication and a DestinationAddress attribute to the Data  
Indication.
Would a client always have to specify a source address attribute in a  
Send Indication, and a server always include a destination address in  
Data indication?

- Philip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 May 2007 07:45:22 +0300

Hi,

inline:

Philip Matthews wrote:
> I assume you are talking about adding a SourceAddress attribute to the 
> Send Indication and a DestinationAddress attribute to the Data Indication.

Yes.

> Send Indication, and a server always include a destination address in 

It would if the relay allocated more than one address. If the client (or 
the relay) did not specify anything, it would mean IPv4.

Cheers,

Gonzalo

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 30 May 2007 09:07:06 +0300

Hello,

> the Send Indication and a DestinationAddress attribute to the Data

Exactly.

> Send Indication, and a server always include a destination address in

For Data indication, I guess it's needed unless the allocation has only one 
server address of the source address family (in which case the client may 
infer the server address from the source address family).

For Send Indication, as Gonzalo said source address can be optional for IPv4, 
but also if the allocation has only one address of the same family as the 
destination.

Are you concerned with bandwidth, complexity or curious, or...?

I do not have any very strong opinion. One option would be to enforce a single 
server address per family and per allocation; Then we do not need these 
Destination in Data indication neither Source in Send indication. Maybe we 
should solicit feedback from the v6ops WG on that issue, eh?

-- 
Rémi Denis-Courmont

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 May 2007 09:10:09 +0300

Hi,

> server address per family and per allocation;

I believe we have rough consensus on using a single address per family, 
and on having the possibility of having multiple addresses per allocation.

Cheers,

Gonzalo

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 30 May 2007 09:19:58 +0300

> and on having the possibility of having multiple addresses per allocation.

Fine, then source-in-Send and destination-in-Data are not really needed.

-- 
Rémi Denis-Courmont

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 May 2007 09:23:49 +0300

Hi,

we agreed on defining the address family as Global IPv6 Unicast Address. 
If, in the future, we decide to define new families (as you pointed 
out), we will need the source-in-send and destination-in-data. 
Therefore, I suggest we are explicit from the beginning and add them 
from day one.

This was my understanding of our discussions, actually.

Cheers,

Gonzalo

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 30 May 2007 09:44:12 +0300

> Therefore, I suggest we are explicit from the beginning and add them

Ok, I might be confused because I do not know how you intend to spell it in 
the next draft. We really need source-in-send if (and only if) there is more 
than one address the server can use for a destination. So it depends what we 
call address family here I guess. This can indeed happen if we have 
different "families" that refer to the same network-layer protocol.

Sorry.

-- 
Rémi Denis-Courmont

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 May 2007 11:06:16 +0300

Hi,

> different "families" that refer to the same network-layer protocol.

exactly. We do not have it in the current draft because we currently 
only have two address families: IPv4 and IPv6. Then, you said that we 
may need to support different IPv6 address types. That is why we agreed 
to defining the global unicast IPv6 address family instead of simply 
IPv6 and add the source-in-send and destination-in-data stuff in case, 
in the future, somebody defines a new address IPv6-related address family.

Cheers,

Gonzalo

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 30 May 2007 12:05:16 +0300

On Wednesday 30 May 2007 11:06:16 ext Gonzalo Camarillo wrote:
> Hi,
>
> > Ok, I might be confused because I do not know how you intend to spell it
> > in the next draft. We really need source-in-send if (and only if) there
> > is more than one address the server can use for a destination. So it
> > depends what we call address family here I guess. This can indeed happen
> > if we have different "families" that refer to the same network-layer
> > protocol.
>

Right. Then it might make sense to not abuse the term "family". I tend to 
associate that with socket protocol/address family and OSI layer-3, hence the 
confusion. That's also how the base TURN spec uses it currently. So any other 
word as category, type, class, label, species, you-name-it, whatever-else 
maybe??

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Wed, 30 May 2007 16:54:11 -0400

My concern about the SourceAddress and DestinationAddress attributes  
is partly overhead and partly additional complexity in TURN.

The first could be addressed by enhancing the SetActiveDestination  
indication to specify the default sending/receiving address so that  
these attributes can be eliminated once the ICE connectivity checks  
are finished.

The second is just because I see STUN and TURN as getting more and  
more complex to handle marginal cases.
Personally, I don't see a reasonable use-case for a TURN relay with  
more than one IPv4 address and one IPv6 address. Unless, some can  
present one, I suggest we design for that case and not insert things  
that are only really useful in future cases that currently seem  
unlikely.
As suggested below, it might be possible to infer the address of the  
TURN-relay-to-destination portion of the path from the address or  
header used on the TURN relay-to-client portion of the path.  I am  
not convinced this is really foolproof, but if it is, then I think  
this is might be a simpler solution than defining the new attributes.

- Philip

On 30-May-07, at 02:23 , Gonzalo Camarillo wrote:

> Hi,
>
> we agreed on defining the address family as Global IPv6 Unicast  
> Address. If, in the future, we decide to define new families (as  
> you pointed out), we will need the source-in-send and destination- 
> in-data. Therefore, I suggest we are explicit from the beginning  
> and add them from day one.
>
>>>> I do not have any very strong opinion. One option would be to  
>>>> enforce a
>>>> single