Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Thu, 18 Oct 2001 11:54:02 +1000

Pekka, 

> >    > Getting a new extension header is hardly a minor change. It needs
> >    > _every_ IPv6 forwarding engine to be changed, thus affecting the
> >    > ipv6 WG's scope. 
> > 
> >    	=> Huh ?? Are you saying routers have to be upgraded
> >    	every time we have a new DST-option addressed to the
> >    	end host ?
> >    	Thats news to me.
> >    
> > => some remarks:
> >  - the change is a new final header, not an extension one (ie it will
> >    be always the last one) nor a destination option
> >  - no IPv6 forwarding engine needs to be changed, the only header
> >    processings are for the IPv6 header and for an optional hop-by-hop
> >    header (so it must be just after the IPv6 header and unique).
> >    The forwarding engine verifies the next header field is not zero,
> >    it should not check if it knows it (i.e. you have not to upgrade
> >    your router in order to support SCTP for instance).
> 
> True.
> 
> But the sending node will have to know that the destination will support 
> this new header, else the packet is discarded.
> 
> Especially if destination is CN, this may or may not be possible.
> 
	=> Agreed. Hence the need for a standard ! 
	The Home Address option MUST be supported by 
	all IPv6 nodes. This solves your concerns. 
	The BU option and potentially the new ext header
	SHOULD be supported .... voila. 

> Yesterday, I posted a related note to on ipng list with subject:
> "Extension Header Capability Discovery needed?", which may be of interest.
> 
	=> In this case this adds another unnecessary round trip
	that is already made redundant by the KEYWORDS. 
	But perhaps this proposal can be useful for other 
	applications of ext headers.

	Hesham

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 17 Oct 2001 20:09:23 -0700

>      But the sending node will have to know that the destination will
>      support this new header, else the packet is discarded.
> 

If both BU and the new header are optional, header type of BU
is recognized, that of the new header is not. Filtering forwarders
not knowing these options will possibly let the BU go through (knowing
at least the destination header type), but they do not know the new
header, most likely dropping it. This may be a problem.

-Jari

---

From: Michael Thomas <[email-masked]>
Date: Thu, 18 Oct 2001 08:21:30 -0700 (PDT)

> header, most likely dropping it. This may be a problem.

   This is a problem with any new protocol or well
   known port. If we are constrained by fascist firewall
   administrators, we have exactly two choices:

   1) Tunnel everything through port 80
   2) Shut down the IETF

	   Mike