Subject: [pim] null register dummy ip header

From: Tom Pusateri <[email-masked]>
Date: Mon, 19 May 2003 14:23:33 -0700

If you're on the I2 multicast mailing list, you've no doubt noticed
a thread on the null register dummy IP header. It seems that it
is under specified in all versions of the PIM sparse mode spec
and so we should update the latest spec to clearly specify which
fields are filled in.

The current language is:

        For (S,G) null Registers, the Multicast data packet portion 
        contains only a dummy header with S as the source address, G as
        the destination address, and a data length of zero.

What isn't specified is whether the rest of the IP header fields
should be filled in.

Juniper has only ever zero'ed the whold IP header, and filled in
the group and source addresses.

Others seem to fill in the IP version, header length, and checksum.

Since there is no other checksum over the group and source address,
it makes sense to use this checksum, though, we will have problems
with interoperability if we require it now.

As Dino pointed out, filling in the IP version allows V6 registers
inside V4 encapsulations as vice versa.

So it sounds like we need to beef up this section of the draft.

Thanks,
Tom
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: Mark Handley <[email-masked]>
Date: Mon, 19 May 2003 14:55:31 -0700

>So it sounds like we need to beef up this section of the draft.

How about we suggest (in addition to the existing text): 

With IPv4, with respect to the fields in the dummy header, an
implementation SHOULD fill in the checksum field.  Framentation offset
MUST be zero.  If the checksum field is filled in with a non-zero
value, the IP version, header length and total length fields MUST be
filled in.  If the header length field is filled in, it MUST have a
value of 5, indicating no IP options are present.  If total length is
filled in, it MUST have a value of 20.  If the Header Checksum field
is non-zero, the recipient SHOULD check the checksum and discard null
registers that have a bad checksum.  If the Header Checksum field is
zero, the recipient MUST NOT check the checksum.

And something similar with IPv6.

What do we specify for the Protocol field?

Cheers,
	Mark

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 19 May 2003 19:02:28 -0700

>What do we specify for the Protocol field?

Sounds good so far. I received a question about TTL too. We should
specify that. I suggest similar language like "If the IP TTL is filled in,
it MUST be 1." As far as protocol number, I think 0 is appropriate.

Thanks,
Tom

---

From: Mark Handley <[email-masked]>
Date: Mon, 19 May 2003 20:08:05 -0700

>it MUST be 1." 

The reason I didn't specify this was that so long as it's covered by
the checksum, it doesn't matter what value it has.  The other fields
mattered because they all had secondary effects.  Similarly it doesn't
matter what value the diffserv or ECN bits have.  So a MUST for this
seems too strong to me.

>As far as protocol number, I think 0 is appropriate.

Hmm, for IPv6, protocol 0 is a hop-by-hop option.  So probably better
to avoid this for IPv4 too.  How about 103 (PIM)?

Cheers,
	Mark

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 20 May 2003 13:00:05 +0900

>>>>> On Mon, 19 May 2003 14:55:31 -0700, 
>>>>> Mark Handley <[email-masked]> said:

> And something similar with IPv6.

Hmm, but IPv6 does not have a checksum field in its base header:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(from Section 3 of RFC 2460)

So, if we really need to care about this for IPv6, we may have to
either:

- add a (dummy) PIM header after the inner IPv6 header, and put the
  checksum for the inner headers there.
- reuse a different field of the inner basic IPv6 header (e.g. the
  payload length field) for this specific checksum.
- (there may be other options)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: Rajamanickam jaganbabu <[email-masked]>
Date: Thu, 22 May 2003 12:07:16 +0100 (BST)

Hi guys, 

I have a funny doubt, In the Null register message, instead of sending a dummy ip header why don't we send a direct group address (group format) and source address (unicast format). 

I hope if we do in the above manner, we won't have the problems and debates of setting the different values in the IP headers. 

It would be great if anybody could tell me why we can't do as the above which I have mentioned.

  Sorry for the delay

Thanx,

Jags

JINMEI Tatuya / 神明達哉 <[email-masked]> wrote:
>>>>> Mark Handley said:

JINMEI, Tatuya

Catch all the cricket action. Download Yahoo! Score tracker