Subject: [ipcdn] Re: DVB CableNetwork Interface Unit MIB.

From: [email-masked]
Date: Mon, 14 Aug 2000 13:46:29 +0100

Jens,

Thanks for the feedback on the MIB, hopefully I have answered all you
questions:-

> I have a number of items that I want to discus.

> Multicast:
> I still think it would be a good idea to have separate settings for
> enable and disable multicast upstream and downstream.
> The purpose is to minimize the traffic on the cable.

If I add the switch to enable/disable multicast, what exactly would it
enable/disable? e.g. IGMP, any traffic on a mulitcast IP address?  For the
latter, an IP filter would be sufficient.

> IP Filters
> We have started to look at the IP filters and I have some questions.
> I hope you can help me with the answers.

> 1) Under dvbNiuIpFilterTable is stated that "Packets which match no
filters
> will be discarded".
> Will a packet that once has passed a filter row with dvbNiuIpFilterAction
> set to Accept and dvbNiuIpFilterContinue set to TRUE
> be discarded when it reach the end of the filter table?

the packet would not be discarded because there was a filter hit.  I will
clarify the description.

> 2) Is it implicit that NAT/NAPT are not applied to broadcast and
multicast
> addresses?

The filter table does not prevent you from applying NAT/NAPT to
broadcast/multicast addresses, do you see a problem with this?

> 3) Should there be a NAT/NAPT action applied to both directions?
> Or this action only for upstream direction and then implicit on the
> downstream direction
> if enabled upstream?
> You can not just use the same filter in both directions, since
> in the upstream it should be applied to some source (and destination)
addresses
> and in the downstream it should be applied to a specific destination
address.
> I assume the translation (IP/port) => port only can be applied upstream.

A NAT/NAPT filter always has a implicit inverse function e.g. if I set up a
filter to perform NAPT in the upstream direction, then any packets sent
downstream to the NAPTed address will be translated.

The NAPT was intended only for the upstream direction,  I will explicity
state this in the MIB.

> 4) In the anti-spoofing case, filter rows are created automatically!!!
> This leads the a number of questions.

It certainly does!

> 4a) What will the dvbNiuIpFilterIndex be in that case?
> A low or a high or a random number?
> The highest available number?
> This is important for the order of the filtering.

I had overlooked this problem, thanks for spotting it.  The antispoofing
filters need to be applied before any other filters.  To solve this, the
first x filter entries could be reserved for anti spoofing filters or we
move the anitspoofing filters to a separate table.

> 4b) The MIB states that the CPE address set trough DHCP relay
> should be non-volatile, at least until released by DHCP release or the
> operator.
> In practice the modem could easily miss the DHCP release
> because the CPE is never used again or the modem is turned off.
> Isn't it a bit dangerous to have this kind of automatically created,
> non-volatile filter rows?

This is an interesting problem.  Support for anti spoofing is a requiement
along with DHCP address assignment for customer PCs.  Unless operators tie
IP addresses to MAC addresses for customer PCs, manually entering
anti-spoof filters could become a burden.  The solution was to sniff the
DHCP and automatically generate the filters. The reason for non-volitile
was to cater for the CDM benig switched off or rebooted while and loosing
the filter for a valid IP address.  The problem this introduces, as you
have identified is that if the DHCP releases are missed, the addresses will
not be deleted, and will require the operator to manually remove them.  If
you have any ideas on how to solve this problem please let me know.

Andy
--
Andrew Valentine
Systems Engineer
Hughes Network Systems Europe Ltd.
Linford Wood , Saxon Street, Milton Keynes MK14 6LD, United Kingdom
Tel     : Direct +44 1908 326 233 Tel Main +44 1908 221122 x 233
Fax    : +44 1908 221127
Email: [email-masked]

#**********************************************************************
This message is intended solely for the use of the individual
or organisation to whom it is addressed. It may contain
privileged or confidential information.  If you have received
this message in error, please notify the originator immediately.
If you are not the intended recipient, you should not use,
copy, alter, or disclose the contents of this message.  All
information or opinions expressed in this message and/or
any attachments are those of the author and are not
necessarily those of Hughes Network Systems Limited,
including its European subsidiaries and affiliates. Hughes
Network Systems Limited, including its European
subsidiaries and affiliates accepts no responsibility for loss
or damage arising from its use, including damage from virus.
#**********************************************************************

_______________________________________________
IPCDN mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/ipcdn