Subject: RE: uni-based-mcast and malloc-ipv6-guide

From: "Dave Thaler" <[email-masked]>
Date: Mon, 17 Sep 2001 12:25:13 -0700

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Monday, September 17, 2001 11:23 AM
> 
> > See RFC 2908.
> 
> At least that reference is missing from the document.
> But I see a mismatch between the draft and RFC 2908 since the latter
> seems to say that an application can request multicast addresses with
> a particular lifetime. With the uni-based addresses there can be no
> way for the application to request a lifetime.
> How can this be resolved?

What makes you think there isn't a way for the app to request a
lifetime?
RFC 2771 applies to all dynamic multicast addresses.
 
-Dave 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 Sep 2001 22:11:25 +0200 (CEST)

> RFC 2771 applies to all dynamic multicast addresses.

Huh?

How does the application requesting a particular lifetime effect the
lifetime that the routers use when advertising the unicast prefix?

Are you envisioning some new protocol to inform the routers (and the system
admin, ISP, RIR) that allocated the unicast prefix that it needs to
stay around for long enough to satisfy the applications request? :-)

So while there might be an abstract API that allows the application
to ask, the scheme in uni-based-mcast doesn't seem to have the pieces
so that the system can honor such a request; at least not with a strict
interpretation of the relationship between the RFC 2462 notion of lifetime
of the unicast prefix, and the presumed lifetime of the derived multicast'
address.

Hence my question whether the intent is to have such a strict relationship
or not.

   Erik

---

From: "Suresh Krishnan" <[email-masked]>
Date: Mon, 17 Sep 2001 14:20:55 -0700

Hi all,
    I might be totally wrong in this but I see that there are two
contradicting statements in RFC1883 for IPv6. Can somebody please explain

Page 7

statement a:
   Each extension header should occur at most once, except for the
   Destination Options header which should occur at most twice (once
   before a Routing header and once before the upper-layer header).

statement b:
   IPv6 nodes must accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet,
   except for the Hop-by-Hop Options header which is restricted to
   appear immediately after an IPv6 header only.

I am sorry if this has already been raised as a question and answered.

Thanks in advance,
Suresh

---

From: Steve Deering <[email-masked]>
Date: Mon, 17 Sep 2001 14:37:54 -0700

Suresh,

This is just an example of the Internet robustness guideline:
"be conservative in what you send and liberal in what you receive".
If you recognize statement (a) as applying to senders, and (b) as
applying to receivers, you will see that they are not contradictory.
Also, note the "should" (rather than "must") in statement (a).

Steve

---

From: Matt Crawford <[email-masked]>
Date: Mon, 17 Sep 2001 16:52:21 -0500

> contradicting statements in RFC1883 for IPv6. Can somebody please explain

The apparent discrepancy is reconciled by the robustness principle.

  2.10.  Robustness Principle

    TCP implementations will follow a general principle of robustness:  be
    conservative in what you do, be liberal in what you accept from
    others.

This applies not only to TCP - see RFC 1812.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Sep 2001 17:25:09 -0500

The general statement is in RFC 1958:

>    3.9 Be strict when sending and tolerant when receiving.
>    Implementations must follow specifications precisely when sending to
>    the network, and tolerate faulty input from the network. When in
>    doubt, discard faulty input silently, without returning an error
>    message unless this is required by the specification.

   Brian