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-
> >