Re: Comments on draft-nordmark-multi6-threats-01

Iljitsch van Beijnum <[email protected]>
Newsgroups gmane.ietf.multi6
Message-ID <[email protected]>
On 8-jun-04, at 1:14, Erik Nordmark wrote:

>>>       identifier  - an IP layer identifier for an IP layer endpoint
>>>                     (stack name in [NSRG]).  The transport endpoint 
>>> is a
>>>                     function of the transport protocol and would
>>>                     typically include the IP identifier plus a port
>>>                     number.

>> Do we believe there may be multiple identifiers per interface or per 
>> host?

> I think there is utility to have multiple identifiers per stack/host.
> For example due to privacy concerns, when using different (and 
> changing over
> time) identifiers for certain outbound connections while still having
> one (or more) identifiers for inbound communication.

One very pragmatic reason: if you allow only one management becomes a 
nightmare as any identifier change is a flag day event. (This is why 
RFC 2385 never got off the ground until people were convinced the net 
as a whole would melt down without it.)

> Should we make it explicit that the identifiers are not (necessarily) 
> tied
> to an interface?

Yes, and we should make it very clear that an identifier that can be 
used on one interface (physical or otherwise) MUST also be usable as an 
identifier on any other interface (physical or otherwise) that the 
system has available. Identifiers should be tied to hosts, not to 
interfaces.

On a related note: the SEND CGA stuff mandates using the subnet prefix 
in creating the interface identifier and as such makes it impossible to 
have the same interface identifier in different subnets. I was unable 
to convince them of the error of their ways and apparently there was no 
IETF last call or I missed it so now this stupidity is an RFC. We 
should do our best to make sure there isn't any more of this.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.