Subject: [Isis-wg] Comments on IS-IS for IPv6

From: "Philip Christian" <[email-masked]>
Date: Fri, 16 Mar 2001 17:34:22 -0000

First, I noticed that the draft-ietf-isis-ipv6-01.txt appears to have timed
out.
I think that it is important to have something that says how IPv6 should be
routed with IS-IS and so this should be re-submitted.
If Christian wants any help with this then I would be pleased to help.

I also have some comments on the draft.

It says in section 7 "Based on further study, future versions of this draft
may specify an optional method for encapsulating IS-IS PDUs in IPv6
packets.". My understanding is that this option has been more or less ruled
out for IPv4, and so I guess for IPv6 too. If so then this line could be
replaced with something similar to "IS-IS PDUs will continue to be
encapsulated using ISO 9542 as per RFC 1195."

Also I have a more radical idea.

In RFC 1195 it basically says (in my own words) that if any of network layer
protocol "X" appears in an IS-IS area, then all routers in that area must
support "X", where "X" would be something such as CLNP, IPv4 or IPv6.

The risk is that if an IPv6-only router or routers are accidentally
connected to an existing IPv4 network, that IS-IS in the IPv4 will see the
IPv6 routers as a valid path. If any IPv4 packets are then sent to the IPv6
routers or vice versa then packet loss will occur.

This problem could be solved by adding a clause into the IS-IS for IPv6
draft saying something like this:-
"An IPv6-only router that uses IS-IS for IPv6 shall check that a
neighbouring node supports IPv6 before completing an IS-IS adjacency with
that node. It may do this by inspection of the "protocols supported" field
of IS-IS Hello PDUs that it receives from the neighbouring node. If IPv6 is
not listed in the "protocols supported" field of Hello packets sent by the
neighbour then the IPv6-only router will refuse the adjacency."

It wouldn't really change the rule in RFC 1195, but it would help to protect
against an accidental connection dragging down part of an existing network.

Regards, Philip Christian

Tel (+44) (0)1279 403184 Fax (+44) (0)1279 402500
e-mail [email-masked]
> Registered Company name & Address:  
> Nortel Networks UK Limited, Maidenhead Office Park, 
> Westacott Way, Maidenhead, Berkshire SL6 3QH 
> Company number: 3937799

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 17 Mar 2001 17:50:37 -0800

Philip Christian wrote:

>
>
> First, I noticed that the draft-ietf-isis-ipv6-01.txt appears to have
> timed out.

Christian's reissuing. It's in ADs hands right now and should go
publication anytime soon.

> I think that it is important to have something that says how IPv6
> should be routed with IS-IS and so this should be re-submitted.
>
> It says in section 7 "Based on further study, future versions of this
> draft may specify an optional method for encapsulating IS-IS PDUs in
> IPv6 packets.". My understanding is that this option has been more or
> less ruled out for IPv4, and so I guess for IPv6 too. If so then this
> line could be replaced with something similar to "IS-IS PDUs will
> continue to be encapsulated using ISO 9542 as per RFC 1195."

Nothing has been ruled out. The requirement may or may not arise again.
The 'may specify' here is fine.  But your point is valid in the sense
that since notyhing happened we should nuke the sentence completely
before it goes RFC.

> In RFC 1195 it basically says (in my own words) that if any of network
> layer protocol "X" appears in an IS-IS area, then all routers in that
> area must support "X", where "X" would be something such as CLNP, IPv4
> or IPv6.
>
> connected to an existing IPv4 network, that IS-IS in the IPv4 will see
> the IPv6 routers as a valid path. If any IPv4 packets are then sent to
> the IPv6 routers or vice versa then packet loss will occur.
>
> This problem could be solved by adding a clause into the IS-IS for
> IPv6 draft saying something like this:-
> neighbouring node supports IPv6 before completing an IS-IS adjacency
> with that node. It may do this by inspection of the "protocols
> supported" field of IS-IS Hello PDUs that it receives from the
> neighbouring node. If IPv6 is not listed in the "protocols supported"
> field of Hello packets sent by the neighbour then the IPv6-only router
> will refuse the adjacency."

hmm, isn't that somewhere in 1195 anywherem too lazy to check now ?  You
can't build adjacencies unless protocols supported overlap.

> It wouldn't really change the rule in RFC 1195, but it would help to
> protect against an accidental connection dragging down part of an
> existing network.

Christian, you want to deal with those comments ?  Minor enough to
probably not being a MUST but somehow valid.

    thansk

    -- tony

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: "Christian E . Hopps" <[email-masked]>
Date: Mon, 19 Mar 2001 09:12:42 -0500

> that since notyhing happened we should nuke the sentence completely

I can remove this before I re-submit.

> > Also I have a more radical idea.

[... don't form adj when nlpid of nbr indicates no ipv6 and router is
ipv6 only]

> probably not being a MUST but somehow valid.

I actually coded my implementation this way.  The problem is that this
doesn't solve all the misconfiguration situations.  I think the much
more likely "mis"-configuration will be for a router to be v6 only and
its neighbors dual v4v6. In this case the adjacency will form but v4
traffic will get dropped by the v6 only router.

Further the draft leaves open the above "misconfiguration" state and
implementors are free to actually run multiple SPFs paying attention
to the NLPID in the LSPs so as to restrict the graph to only supported
protocols.  This removes the "all routers must support the same protocols
in an area" restriction.

So, if people feel it is important I think we could add some text indicating
that adjacencies should only form when the intersection of the NLPID
is non-empty.  This will cover the v6 only to v4 only router case, but
not restrict the dual v6v4 to v6 only case.

Chris.

---

From: Jeff Learman <[email-masked]>
Date: Mon, 19 Mar 2001 11:34:48 -0500

>protocols.  This removes the "all routers must support the same protocols

This is a great goal -- to permit mixing within a subdomain, unlike the
way it currently is for IP+OSI.  But  is this sufficient?  I think it
only works if you require all IPV6-capable routers to support IPV4.
Otherwise, you'd have an IPV4-only IS assuming that it can relay packets
through IPV6-only routers.

To make it possible to mix IPV6-only, IPV6+IPV4, and IPV4 only
implementations, we'd need to put the IPV6 IS adjacencies in a
new TLV.  Or are IPV6-only implementations too far in the future
for us to carefully consider them?  (Or did I get this wrong to
start with?)

Another problem with "leaving an implementation free" to discriminate
or not between protocols seems to me like it could cause routes to be
calculated differently by different routers, causing loops or black
holes.  If we do discriminate, shouldn't we require it of all routers
that implement the new RFC?  (Perhaps the answer here is that "some
new implementations can be mixed in areas, some can't". Is this what
we want?)  Forgive me if this was already discussed and I missed it,
but I would recommend requiring the discrimination when running SPF
and see if anyone objects. 

Regards,
Jeff

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 19 Mar 2001 13:04:11 -0800

> not restrict the dual v6v4 to v6 only case.

now, wouldn't you just not advertise any ipv4 prefixes from the ipv6 onliy
router. So no ipv4 traffic would even head towards a ipv6-only router ?
So if an ipv6+ipv4 router forms adjacency, only traffic crossing it would
be ipv6 anyway ?

    -- tony

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 19 Mar 2001 13:05:05 -0800

> not restrict the dual v6v4 to v6 only case.

I just wrote a stupid e-mail. Ignore it, I forgot the transit case ...

    silly me

    -- tony

---

From: "Christian E . Hopps" <[email-masked]>
Date: Mon, 19 Mar 2001 18:13:35 -0500

> through IPV6-only routers.

You are correct.  I suppose I was only thinking about the "IPv6 is a
subset of the IPv4 router set" case.  I really don't think we need to
overly complicate the extension to support any other configurations.

Its worth noting that multiple vendors at this point have implemented
this draft, in part I think because it was so easy. :)

Chris.

---

From: Jeff Learman <[email-masked]>
Date: Mon, 19 Mar 2001 18:49:24 -0500

Chris,

>this draft, in part I think because it was so easy. :)

It may be better than I first thought.  True, we won't be able to
intermix IPV6-only, dual, and IPV4-only.  But we might be able to
mix IPV6 with Dual, just as we can now mix Dual with IPV4.

If there was a configuration option to enable checking protocols-supported
when building both IPV4 FDBs, then we could do this.  Initially,
the IPV4 option would be disabled, so IPV4 FDBs would match between
old and new implementations.  As soon as all IPV4-only routers were
upgraded (I assume we'll have a few years yet to do that), the options
could be enabled, and we could mix Dual and IPV6.  Note that I'm
assuming that checking the option for IPV6 FDBs is required.
Otherwise, I think we get mayhem.

A little careful thought now might really reduce headaches later!

Jeff