Subject: RE: [mobile-ip] Routing headers: design team recommendation

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 28 Jan 2002 19:03:12 +0100

RH can be used for traffic engineering. 
This maybe limited to packets sent within a site
(within the FW domain) due to the security 
concerns but I don't know if that means it's
useless. 

Hesham 

  > -----Original Message-----
  > From: Jean-Michel COMBES 
  > [mailto:[email-masked]]
  > Sent: Monday, January 28, 2002 6:45 PM
  > To: [email-masked]
  > Subject: RE: [mobile-ip] Routing headers: design team recommendation
  > 
  > 
  > Hi,
  > 
  > just one question : are there others cases (eg. protocols) 
  > where RH are used
  > ?
  > 
  > Regards.
  > 
  > JMC.
  > 
  > 
  > France Telecom R&D - DTL/SSR
  > Jean-Michel COMBES, Internet/Intranet Security
  > E-Mail : [email-masked]
  > Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
  > PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214
  > 
  > > -----Message d'origine-----
  > > De : [email-masked]
  > > [mailto:[email-masked]]De la part de 
  > Charles E.
  > > Perkins
  > > Envoye : lundi 28 janvier 2002 18:20
  > > A : Basavaraj Patil (NTC/Dallas)
  > > Cc : [email-masked]
  > > Objet : Re: [mobile-ip] Routing headers: design team 
  > recommendation
  > >
  > >
  > > Hello Basavaraj,
  > >
  > > While I think a new Destination Option will work fine,
  > > I also think the Routing Header would work fine.  If protocol
  > > cannot be built using the Routing Header, then it should
  > > be removed from the IPv6 protocol specification.
  > >
  > > It is a huge waste of time for us to build according to
  > > the IPv6 specification, only to be told later that the
  > > specs were "just kidding" -- e.g., because of firewall
  > > administrative bias.
  > >
  > > Regards,
  > > Charlie P.
  > >
  > >
  > >
  > > [email-masked] wrote:
  > > >
  > > > I agree and am in favor of the DTs recommendation for 
  > replacing the
  > > > RH with a new DO.
  > > >
  > > > -Basavaraj
  > > >
  > > > >  RECOMMENDATION
  > > > > ==============
  > > > >
  > > > > The design team is leaning towards #3 at the moment. One
  > > > > reason for this is that this would remove any 
  > suspicion that firewall
  > > > > administrators have for the use of the Routing Header and
  > > > > which might consequently lead to disabling MIPv6 
  > because of these
  > > > > fears. Also, the firewall rules necessary to process 
  > the Routing
  > > > > Header are complex and accidental disabling of MIPv6 
  > might also
  > > > > occur. The use of the Routing Header for other purposes would
  > > > > also not be affected. There are also drawbacks in 
  > alternative #3.
  > > > > One such issue is that existing MIPv6 implementations have to
  > > > > be changed. We feel that this drawback is offset by 
  > the expected
  > > > > wider usability of MIPv6 as a result. This change 
  > will also imply
  > > > > a substantial document modification for the MIPv6 I-D. This
  > > > > does not appear to be a structural change, however, and in
  > > > > general we feel that direct procedure is easier to 
  > describe than
  > > > > attempting to describe some additional rules to 
  > constrain the use
  > > > > of the Routing Header. Finally, alternative #3 might 
  > lead us to
  > > > > depend on the external work such as the new tunnel 
  > encapsulation
  > > > > work at IPNG. The design team feels that we should stay away
  > > > > from these non-MIPv6 solutions due schedule issues as well
  > > > > as in the interests of making a self-contained RFC.
  > > > >
  > > > > ---
  >