Regarding route calculation over Vlink in case of OSPFv3
prasanna s <KSPrasanna@HUAWEI.COM> Wed, 21 July 2004 05:28 UTC
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19362 for <ospf-archive@LISTS.IETF.ORG>; Wed, 21 Jul 2004 01:28:56 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00E2037A@cherry.ease.lsoft.com>; Wed, 21 Jul 2004 1:28:54 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 26845477 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 21 Jul 2004 01:28:53 -0400
Received: from 61.144.161.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 21 Jul 2004 01:18:52 -0400
Received: from PRASANNACL1222 (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0I1600DENRKBU2@mta1.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 21 Jul 2004 13:07:25 +0800 (CST)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
X-imss-version: 2.5
X-imss-result: Passed
X-imss-approveListMatch: *@huawei.com
References: <BB6D74C75CC76A419B6D6FA7C38317B22E84C4@sinett-sbs.SiNett.LAN>
Message-ID: <002901c46ee2$eb271d90$9904120a@in.huawei.com>
Date: Wed, 21 Jul 2004 10:53:54 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: prasanna s <KSPrasanna@HUAWEI.COM>
Subject: Regarding route calculation over Vlink in case of OSPFv3
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit
Iam running OSPFv3 in the following topology vlink +++++++++++++++++++++++++++++++++++ + + RTA(e1)-------------(e1)RTB(e2)------------(e2)RTC(e3)------| 2000:cccc::1/128 area 1 area 1 area 0 in this scenario, What should be the next hop for the route 2000:cccc::1/128 in the routing table of RTA Is it link-local address of e1 of RTB or Global/site-local ipv6 address of e2 of RTC or Null Thanx and regards Prasanna Kumar A.S Software Engineer Huawei Technologies India Pvt Ltd Level-3 & 4 ,Leela Galleria, The Leela Palace,No.23 Airport Road. Bangalore-560 008 Mobile : 98803-34587 phone(0ff): 5217474/5217152 ext 701 ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** ----- Original Message ----- From: "Vishwas Manral" <Vishwas@SINETT.COM> To: <OSPF@PEACH.EASE.LSOFT.COM> Sent: Saturday, July 17, 2004 1:17 PM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Hi Abhay/Suresh, Would it help to have different MCast Address for OSPFv2/OSPFv3 over IPv4? Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Suresh Melam Sent: Tuesday, July 13, 2004 11:36 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-ietf-ospf-ospfv3-auth-04.txt Abhay, I've following two observations. - While "Instances" are meant to distinguish multiple instances on a single link, each interface, as mentioned in 2740, will still be assigned a single Instance ID. Any packets received with instance ID different than the one in Interface structure will be dropped by the OSPF. All our IPsec rules/SAs have interface as one of the selector. Thus these SAs will be tied uniquely to an Instance. We will make explicit mention of this point in the draft. - IPsec is meant to provide security at the IP layer and thus most of the selectors are only IP selectors. Special consideration has been given to the port numbers of well-known transport protocols like TCP/UDP and thus they are also included as selectors. The latest IPsec architecture draft (draft-ietf-ipsec-rfc2401bis-02.txt, Sec 4.4.1.1) has added few more selectors that are specific to upper layers, but still hasn't provided any option to specify arbitrary upper layer fields as IPsec selectors. As we expect the underlying IPsec implementations to be standard ones, we cannot enforce any additional requirements to the IPsec implementations. Thus I would conclude that there are no issues with supporting multiple OSPF instances on a single link, but distinguishing OSPFv2 and OSPFv3 packets running over same IPv4 family would be not a viable solution. Please see my followup mail to Vishwas mail for further discussion of this multiple AF issue. thanks, -suresh On Sun, 2004-07-11 at 13:14, ext Abhay Roy wrote: > Suresh, > > I am afraid, we need to have IPsec selector go deeper. Otherwise > we can't allow different OSPFv3 Instance ID's to use different > IPsec security associations (SAs). > > I noticed that draft-ietf-ospf-ospfv3-auth doesn't talk about > possibility of running multiple instance per link, and it's > interaction / implications with IPSec SAs. We should address that. > > Regards, > -Roy- > > On 07/09/04-0700 at 10:52am, Suresh Melam writes: > > > Hi Abhay/Vishwas, > > > > comments inline, > > > > thanks, > > -suresh (Nagavenkata Suresh Melam) > > > > > > >> Hi Vishwas, > > >> > > >> Thanks for the comments. Please see my comments inline.. > > >> > > >> > 1. I am not sure we should have a statement which says OSPFv3 > > >> > is only for IPv6. > > >> > "As OSPFv2 is only for IPv4 and OSPFv3 is only for IPv6, > > >> > the distinction between the packets can be easily made by > > >> > IP version. " > > >> > > >> Do you have a replacement statement that you would prefer ? > > >> As the IP protocol type value for OSPF and OSPFv3 is same, > > >> we have to depend upon the IP version to separate OSPF and > > >> OSPFv3 packets. > > > > > >Just FYI, we can run OSPFv3 using IPv4 transport (see section 9 of > > >draft-mirtorabi-ospfv3-af-alt-01.txt). In which case the demux > > >will be based on OSPF protocol version. > > > > > > > IPsec selectors are not usually any deeper than protocol field of > > IP header and port numbers of UDP/TCP transport protocol. Thus, OSPF > > protocol version cannot be one of the selector. > > > > If OSPFv3 runs on IPv4 transport, there wouldn't be any way > > to distinguish OSPFv3 packets from OSPFv2 packets, as both of them > > use same protocol value. Thus IPsec security, as mentioned in > > "Security considerations" section of RFC2740 and ospfv3-auth draft, > > cannot be provided to these packets. Perhaps this should be mentioned > > in the "Security Considerations" section of ospfv3-af-alt draft. > > > > >Regards, > > >-Roy- > >
- draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Mukesh.Gupta
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Abhay Roy
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Acee Lindem
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Erblichs
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Acee Lindem
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Mukesh.Gupta
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Erblichs
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Mukesh.Gupta
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Erblichs
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Suresh Melam
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Suresh Melam
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Mukesh.Gupta
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Erblichs
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Mukesh.Gupta
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Abhay Roy
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Abhay Roy
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Suresh Melam
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Suresh Melam
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Regarding route calculation over Vlink in case of… prasanna s
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral
- Re: draft-ietf-ospf-ospfv3-auth-04.txt Vishwas Manral