OK
On 18/03/2015 10:13 PM, Fuyu (Eleven) wrote:
Hi Tom,
Thank you for your review and comments.
The main difference for the NAT management between the NATv2-MIB and DSLite-MIB
is that the NATv2-MIB describe the tunnel information on the view of address
level. But the DSLite-MIB define it on the view of interface.
I think the NAT objects defined in DSLite-MIB should make in accordance with
the tunnel management as the TUNNEL-MIB do.
So do you feel OK if I described the following quoted statement as " The tunnel
information defined in NATV2-MIB on the address level for DS-Lite scenario. Because the
TUNNEL-MIB defined the objects on the view of interface, the DS-Lite-MIB need defined the
tunnel objects to extend the NAT binding entry by interface for accordance."
Best Regards
Yu
-----Original Message-----
From: Tom Taylor [mailto:[email protected]]
Sent: Monday, March 16, 2015 8:30 AM
To: Yong Cui; Fuyu (Eleven)
Cc: [email protected] WG; Krishnan Suresh
Subject: Re: [Softwires] WGLC for draft-ietf-softwire-dslite-mib-07
Sorry to let my review of the updated version slip.
I think the key contribution of this document lies in its tunnel management
aspect. I'm concerned that the NAT management part still has a considerable
overlap with the NATv2-MIB
http://www.ietf.org/id/draft-perrault-behave-natv2-mib-02.txt
Using the line numbers contained in the IDNits output generated by the URL at
the bottom of this message, I have to say that the following statement is
incorrect:
<quote>
But the NAT
168 binding entry defined in the NATV2-MIB are not extended by the object
169 definded for the tunnel initiator.
</quote>
Here is what the NATv2-MIB document has, in the address binding table:
natv2AddressMapInternalAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Source address of packets originating from the interior
of the association provided by this mapping.
In the case of DS-Lite [RFC 6333], this is the IPv6 tunnel
source address. The mapping in this case is considered to
be from the combination of the IPv6 tunnel source address
natv2AddressMapInternalRealmAddress and the well-known IPv4
inner source address natv2AddressMapInternalMappedAddress to
the external address."
REFERENCE
"DS-Lite: RFC 6333, Section 5.7 for well-known addresses and
Section 6.6 on the need to have the IPv6 tunnel address in
the NAT mapping tables."
::= { natv2AddressMapEntry 4 }
....
natv2AddressMapInternalMappedAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Internal address actually translated by this mapping. In the
general case, this is the same as
natv2AddressMapInternalRealmAddress. In the case of DS-Lite
[RFC 6333], this is the source address of the encapsulated
IPv4 packet, normally lying the well-known range
192.0.0.0/29. The mapping in this case is considered to be
from the combination of the IPv6 tunnel source address
natv2AddressMapInternalRealmAddress and the well-known IPv4
inner source address natv2AddressMapInternalMappedAddress to
the external address."
REFERENCE
"DS-Lite: RFC 6333, Section 5.7 for well-known addresses and
Section 6.6 on the need to have the IPv6 tunnel address in
the NAT mapping tables."
::= { natv2AddressMapEntry 7 }
and similarly in the port binding table:
natv2PortMapInternalRealm OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The realm to which natv2PortMapInternalRealmAddress belongs.
In the general case, this realm contains the address that is
being translated. In the DS-Lite [RFC 6333] case, this realm
defines the IPv6 address space from which the tunnel source
address is taken. The realm of the encapsulated IPv4 address
is restricted in scope to the tunnel, so there is no point
in identifying it separately."
REFERENCE
"RFC 6333 DS-Lite."
::= { natv2PortMapEntry 7 }
natv2PortMapInternalAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Address type for addresses in the realm identified by
natv2PortMapInternalRealm."
::= { natv2PortMapEntry 8 }
natv2PortMapInternalAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Source address for packets received under this mapping on
the internal side of the NAT instance. In the general case
this address is the same as the address given in
natv2PortMapInternalMappedAddress. In the DS-Lite case,
natv2PortMapInternalAddress is the IPv6 tunnel source
address."
REFERENCE
"DS-Lite: RFC 6333, Section 5.7 for well-known addresses and
Section 6.6 on the need to have the IPv6 tunnel address in
the NAT mapping tables."
::= { natv2PortMapEntry 9 }
natv2PortMapInternalMappedAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Internal address type actually translated by this mapping.
Any value other than ipv4(1) or ipv6(2) would be unexpected.
In the general case, this is the same as given by
natv2AddressMapInternalAddressType. In the DS-Lite
case, the address type is ipv4(1)."
REFERENCE
"DS-Lite: RFC 6333."
::= { natv2PortMapEntry 10 }
natv2PortMapInternalMappedAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Internal address actually translated by this mapping. In the
general case, this is the same as
natv2PortMapInternalRealmAddress. In the case of DS-Lite
[RFC 6333], this is the source address of the encapsulated
IPv4 packet, normally selected from the well-known range
192.0.0.0/29. The mapping in this case is considered to be
from the external address to the combination of the IPv6
tunnel source address natv2PortMapInternalRealmAddress and
the well-known IPv4 inner source address
natv2PortMapInternalMappedAddress."
REFERENCE
"DS-Lite: RFC 6333, Section 5.7 for well-known addresses and
Section 6.6 on the need to have the IPv6 tunnel address in
the NAT mapping tables."
::= { natv2PortMapEntry 11 }
On 13/03/2015 10:34 PM, Yong Cui wrote:
Hi authors,
We would like to advance the document.
Would you please update your document according to the following "Check nits"
report once the submission system opens? I found there are still some issues in your new
version draft-ietf-softwire-dslite-mib-08.
http://www.ietf.org/tools/idnits?url=http://www.ietf.org/archive/id/dr
aft-ietf-softwire-dslite-mib-08.txt
I would also need to receive the confirmation to the chairs from each of your
authors on the IPR issue:
Has each author confirmed that any and all appropriate IPR disclosures required
for full conformance with the provisions of BCP 78 and BCP 79 have already been
filed. If not, explain why?
Thanks in advance,
Yong
On 2015-2-9, at 上午10:44, Fuyu (Eleven) <[email protected]> wrote:
Hi Tom
Yes. I have updated the DS-Lite MIB based on draft-perrault-behave-natv2-mib.
Your review and comments will be very appreciated.
Thanks
BR
Yu
-----Original Message-----
From: Softwires [mailto:[email protected]] On Behalf Of Tom
Taylor
Sent: Friday, February 06, 2015 5:34 AM
To: Yong Cui; [email protected]
Subject: Re: [Softwires] WGLC for draft-ietf-softwire-dslite-mib-07
I finally got around to looking at this document, but I see I'm a bit late. In
any event, I believe the authors are updating it based on the fact that
[I-D.ietf-behave-nat-mib] is being replaced by draft-perrault-behave-natv2-mib.
I will be happy to review the updated draft, because coordination between the
two drafts is clearly required.
Tom Taylor
On 21/01/2015 7:05 AM, Yong Cui wrote:
Hi folks,
This message starts a two week softwire working group last call on
advancing the draft of DS-Lite MIB as a Standards Track RFC.
After we had the first wglc on draft-ietf-softwire-dslite-mib-02,
there were some major comments. The authors have revised the
document including the structure and detailed technical contents.
Now the authors believe that this version has addressed all the
issues.
The latest version of the draft is available at:
http://www.ietf.org/id/draft-ietf-softwire-dslite-mib-07.txt
Substantive comments and statements of support/opposition for
advancing this document should be directed to the mailing list.
Editorial suggestions can be sent directly to the authors. This last
call will conclude on February 3, 2015.
Thanks,
Yong & Suresh
...
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
