I-D Action:draft-ietf-6man-addr-select-sol-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : Solution approaches for address-selection problems
	Author(s)       : A. Matsumoto, et al.
	Filename        : draft-ietf-6man-addr-select-sol-02.txt
	Pages           : 20
	Date            : 2009-07-01

In response to address selection problem statement and requirement
documents, this document describes approaches to solutions and
evaluates proposed solution mechanisms in line with requirements.  It
also examines the applicability of each solution mechanism from the
viewpoint of practical application.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-sol-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org

Re: Implementation specific Interface-ID

Hi Thomas,
I have an interface that is shared by multiple virtual hosts on the box, each of
which requires autoconf addresses. The one standard address can't be shared
as, in my implementation, the IP address is the one that uniquely identifies
the virtual host for an incoming connection.

These addresses can failover to other interfaces or other nodes on the
same link.
Also, the cost of generating a duplicate address on the link is very
high, in terms
of client outage. Since these addresses are automatic, everything is expected to
work seamlessly as there may be no administrative involvement (as against
manually configured addresses).

I did consider using vlans but this requires huge changes in existing network
topology and switch-side re-configurations.

Is there a standard solution for this kind of problem?

Thanks & Regards
Vijay

On Wed, Jul 1, 2009 at 1:08 AM, Thomas Narten<narten <at> us.ibm.com> wrote:
> BTW, why do you want or need to do this? Why do you not not want to
> generate a standard Interface Identifier like everyone else?
>
> Thomas
>
>> Hi Everyone,
>

Re: Implementation specific Interface-ID

Vijayrajan ranganathan wrote:
> I did consider using vlans but this requires huge changes in existing network
> topology and switch-side re-configurations.

> Is there a standard solution for this kind of problem?

One often used solution is that either the host OS or another virtual OS 
functions as a router between all the virtual OSes and the outside world.

Another solution is that some virtualization platforms (at least vmware 
and xen afaik) offer unique generated MAC addresses to each virtual OS, 
so the standard EUI-64 method will yield unique IIDs.

--

-- 
	Aleksi Suhonen, Research Assistant
	Department of Communications Engineering
	Tampere University of Technology
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Re: Implementation specific Interface-ID

On Thu, Jul 02, 2009 at 12:40:20PM +0530, Vijayrajan ranganathan wrote:
> Is there a standard solution for this kind of problem?

On some OSes it is possible to control the host part of the
autoconfigured address by manually configuring a link local address
before the interface is brought up. The host part of this address
is then used for the rest of the autoconfiguration process. I've
done this on older versions of FreeBSD.

	David.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Re: Any comments on draft-fairhurst-6man-tsvwg-udptt-01

   Hello,

I take the freedom to move this to 6man mailing list...

On Thu, 02 Jul 2009 19:30:54 +0100, Gorry Fairhurst <gorry <at> erg.abdn.ac.uk>
wrote:
> Have you any comments on:
>
> draft-fairhurst-6man-tsvwg-udptt-01
>
> I am trying to figure-out whether this is a good thing to work further
> on.

Canonically, you would use UDP-Lite for this. Of course, UDP-Lite is
impractical in IPv4 due to incompatible middleboxes, especially NAPTs. But
as it comes to IPv6, I do not see this as a real problem with UDP-Lite over
*IPv6* (contrary to IPv4).

Admittedly, UDP-Lite over IPv6 will still have problem, should there be
v4-v6 protocol translation (PT) on the path (I think that was Dave Thaler's
counter-argument at the last meeting). I am not convinced that this is a
serious case here, as it seems dubious to me that we will see UDPTT through
protocol translators. But lets say we will.

Then I would like to know why and how UDPTT will work better than UDP-Lite.
Namely, I would like to know how UDPTT/IPv6<->checksum-free UDP/IPv4
translation is supposed to happen, why IPv4 middleboxes won't explode on
the resulting packets, and how it solves the checksum performance issue. I
am not in any way implying that this is possible or impossible or anything

I-D Action:draft-ietf-6man-overlap-fragment-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : Handling of overlapping IPv6 fragments
	Author(s)       : S. Krishnan
	Filename        : draft-ietf-6man-overlap-fragment-03.txt
	Pages           : 7
	Date            : 2009-07-02

The fragmentation and reassembly algorithm specified in the base IPv6
specification allows fragments to overlap.  This document
demonstrates the security issues with allowing overlapping fragments
and updates the IPv6 specification to explicitly forbid overlapping
fragments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-overlap-fragment-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org

Re: [BEHAVE] Modified EUI-64 format

Le 3 juil. 09 à 19:01, Dave Thaler a écrit :

>>>> The use of the universal/local bit in the Modified EUI-64 format
>>>> identifier is to allow development of future technology that can
>> take
>>>> advantage of interface identifiers with universal scope.

First to be noted: this discussion is only about 64 bit-IIDs on IPv6  
links.
It needs not to interfere with that on IPv6 addresses whose lower  
bits are never used as IIDs on IPv6 links.

Now on this subject, the sentence that IMHO is even more a problem is  
that which precedes the sentence you quoted:
"IPv6 nodes are not required to validate that interface identifiers  
created with modified EUI-64 tokens with the "u" bit set to universal  
are unique."

As we know, the only escape mechanism to define new IID types is <u',  
g> = <1, 1> (where u' stands for u inverted from EUI-64).
The effect of the sentence above is that the only escape mechanism  
can be used ONLY for new _universal-scope_ IIDs.
This ONLY could however be relaxed because, as long as new IID types  
are not defined yet, all node stacks that have u' = 1 in their IIDs  
also have g = 0.
Stacks that may in the future have both u' and g set to 1 in their  
local IID can therefore have a different behavior without  
incompatibility with the installed base.

Re: [BEHAVE] Modified EUI-64 format

On 2009-07-04 10:52, Rémi Després wrote:
> 
> Le 3 juil. 09 à 19:01, Dave Thaler a écrit :
> 
>>>>> The use of the universal/local bit in the Modified EUI-64 format
>>>>> identifier is to allow development of future technology that can
>>> take
>>>>> advantage of interface identifiers with universal scope.
> 
> First to be noted: this discussion is only about 64 bit-IIDs on IPv6 links.
> It needs not to interfere with that on IPv6 addresses whose lower bits
> are never used as IIDs on IPv6 links.

If you read the text in RFC 4291 (and its predecessors), it is clearly
intended to be broader than that:

>>    The use of the universal/local bit in the Modified EUI-64 format
>>    identifier is to allow development of future technology that can take
>>    advantage of interface identifiers with universal scope.

That isn't restricted to the notion of a link as such; or if you prefer,
it also applies to virtual links, and SIIT synthesizes a virtual link
under its PREFIX.

This matters if any variant of the routing architecture is adopted
which resembles 8+8 and its descendants. IIDs need to be globally
unique then, so tramping on the g bit would be a problem. So in fact,
although the authority is 6man, the debate would need to be wider.

Note, I'm not necessarily disagreeing with you; but this is a very

Re: Any comments on draft-fairhurst-6man-tsvwg-udptt-01

Rémi Denis-Courmont wrote:
>    Hello,
> 
> I take the freedom to move this to 6man mailing list...
> 
Thanks, please see below.

> On Thu, 02 Jul 2009 19:30:54 +0100, Gorry Fairhurst <gorry <at> erg.abdn.ac.uk>
> wrote:
>> Have you any comments on:
>>
>> draft-fairhurst-6man-tsvwg-udptt-01
>>
>> I am trying to figure-out whether this is a good thing to work further
>> on.
> 
> Canonically, you would use UDP-Lite for this. Of course, UDP-Lite is
> impractical in IPv4 due to incompatible middleboxes, especially NAPTs. But
> as it comes to IPv6, I do not see this as a real problem with UDP-Lite over
> *IPv6* (contrary to IPv4).
> 
I also suggested this and if UDP-Lite satisfies the need, I'd be
happy to see this used - I would see that increasing UDP-Lite support 
has wider benefit.

> Admittedly, UDP-Lite over IPv6 will still have problem, should there be
> v4-v6 protocol translation (PT) on the path (I think that was Dave Thaler's
> counter-argument at the last meeting). I am not convinced that this is a
> serious case here, as it seems dubious to me that we will see UDPTT through
> protocol translators. But lets say we will.

Re: Any comments on draft-fairhurst-6man-tsvwg-udptt-01

Gorry Fairhurst wrote:
> Rémi Denis-Courmont wrote:
[...]
>> Also, it might be worth to have an socket API consideration appendix...
>>
> Yes, it would need a small API update to work - this can be described if 
> people want to progress this.

Just a socket option would be enough. I kind of feel like there should
not be a standard API though. It should only be used in a few special
cases where a standard API may not be needed. If there is a standard
API, it might be tempting to use this in general...

Stig

> I think the main question we face is which approach to advocate:
> * UDP
> * An updated UDP with no checksum
> * UDP-Lite
> * A UDP-Lite profile (e.g. only minimal coverage)
> * UDPTT
> 
> I don't know if I answered your questions.
> 
> Best wishes,
> 
> Gorry
> 
> 
> --------------------------------------------------------------------