Hi James,
I looked at 3768, which references 1256 as info and only refers to it as
one of several ways a host might get an IPv4 address. As
vrrp-unified-spec-02 was heavily based on 3768 for its IPv4 sections,
this explains why it doesn't discuss this. Ignoring unified question
for a moment, it looks to me that a 3768 compliant backup not running
1256 of a (3768 compliant) master that was running 1256 could hose a
1256 client.
The question is what, if anything, to do? As editor, first I'd like to
do nothing as 3768 was silent. Failing that, maybe clone 8.2.3 into
8.1.x and mention possibility of 1256? My understanding is that editor
is in a "waiting for guidance" mode just now; the vrrp list is silent,
so I've copied the necessary folks.
Thanks,
Steve
-----Original Message-----
From: James Carlson [mailto:james.d.carlson at sun.com]
Sent: Thursday, October 30, 2008 14:28
To: Stephen Nadas
Cc: vrrp at ietf.org
Subject: late question/comment on vrrp-unified-spec-02: IPv4
equivalence
I searched the list, and found no mention of this issue.
Apologies if my searching-fu is insufficient, and it's
already been dealt with, and also because I know that this is
an awfully late time to be bringing up a question like this.
Section 8.2.3 of the I-D goes into detail about handling IPv6
Router Advertisements, and that's probably a good thing, but
there's no equivalent language for IPv4 in section 8.1.
IPv4 also has ICMP router discovery, just like IPv6, and it
works in much the same way. A loss of this service would
cause an outage for networks reliant on it, just as much as a
loss of RA is an outage for IPv6, and even though the
fail-over itself "works." The RDISC entries in existing
hosts will age away, and new hosts will be completely in the
dark. Shouldn't the proper operation of RFC 1256 be included?
In that same vein, it's not actually just ICMP router
discovery that may be at issue here. Different network
deployments use different router-to-host signaling mechanisms
for basic routing information needed by hosts. In some
cases, for v4 at least, that can be delivered by DHCP. But
in other cases, it might be simple RIP default route
advertisements. It's unclear why, when used as an "output only"
router discovery mechanism, RIP would be excluded.
Instead of treating this issue as v6-specific and RDISC-only,
might it be better to have a section that explains that all
router-to-host configuration signaling needs to be preserved
by the current Master?
(And then, if you like, enumerate some known examples, such
as IPv4 and IPv6 RAs.)
I suspect that naming only IPv6 RAs as an issue could lead to
uneven implementation by the unwary.
--
James Carlson, Solaris Networking
<james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1
781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1
781 442 1677
_______________________________________________
vrrp mailing list
vrrp at ietf.org
https://www.ietf.org/mailman/listinfo/vrrp