[Capwap] About NAT issue

Dear Dan:

Thanks for your reply.
Yes, for NAT info offered by MIB, we never discussed it before. If we intend to have it, I think adding
an additional object which indicates a WTP's local address may be more meaningful than a 
object indicating NATed or not.

To Pasi: Some time ago, I ever sent a email about NAT issue which gives a MIB change required.
Please check it, Thanks.

Regards
Richard

----- 原邮件 -----
从: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
日期: 星期二, 一月 26日, 2010 上午0:36
主题: RE: comments to Pasi's opinion (draft-ietf-capwap-base-mib)

> Comments on two of the points. 
> 
> Dan
> 
> 
> > -----Original Message-----
> > From: Pasi.Eronen@nokia.com [Pasi.Eronen@nokia.com] 
> 
> > >> - A question: Did the WG consider including NAT-related 
> > information 
> > >> CapwapBaseWtpStateEntry? For example, whether NAT was 
> > detected, and 
> > >> what the other address (depending on the question above) was?
> > >> [Richard]
> > >
> > > Yes, CAPWAP has NAT Considerations. But other tunnel 
> > protocol (suppose 
> > > GRE or any other example) may also have such function.  I 
> > think there 
> > > should have a generic MIB interface (no matter it exists or 
> > not) Which 
> > > would offer NAT-related information, while such function is 
> > not A part 
> > > of CAPWAP MIB (or other similar tunnel protocol).
> > 
> > I disagree. The NAT traversal functionality here is a 
> > functionality of the CAPWAP protocol, and probably cannot be 
> > managed by any generic MIB. 
> > 
> > However, the question I asked was whether this was discussed 
> > in the WG. Chairs, you do recall?
> 
> I do not remember this having been discussed. 
> 
> As now written the CapwapBaseWtpStateEntry presents the WTP 
> informationwhatever the topology is NAT-ed or not. This seems to 
> me OK as a
> starting point. What Pasi asks if I read correctly is to add columnar
> object that describes whether the connection is NAT-ed and what is the
> IP address visible from the AC. 
> 
> > 
> > > >- capwapBaseMacAclId: this seems to limit the number of 
> > ACL entries 
> > > >to
> > > >255 -- why? (although RFC 5415 doesn't support sending 
> > more than 255 
> > > >ACL entries in a single "Add MAC ACL Entry" message 
> > element, the AC 
> > > >could send more than one of those)
> > >
> > > [Richard] You are correct, it is not required to give a 
> > scope limit to 
> > > the capwapBaseMacAclId. The editors misunderstood the value 
> 255 
> > > mentioned in the RFC5415.
> > 
> > OK.
> > 
> > >> - capwapBaseWtpProfileWtpStaticIpType: How would the 
> > "ipv4z" type be 
> > >> used by the CAPWAP protocol? (it doesn't seem to use the 
> > zone index 
> > >> in any way)
> > >
> > > [Richard] In fact, I am not sure. Dan, Could you confirm 
> whether 
> > > CAPWAP support it?
> > 
> > OK; looking forward to hearing the answer...
> 
> I do not think it's supported, but I would suggest that the protocol
> experts confirm this. 
> 
> 
> > 
> > Best regards,
> > Pasi 
> > 
> > 
> 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap