From J.Renouard@F5.com Wed Jan 2 14:28:32 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74D421F87D4 for ; Wed, 2 Jan 2013 14:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.668 X-Spam-Level: X-Spam-Status: No, score=-9.668 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBYHel2mp5CY for ; Wed, 2 Jan 2013 14:28:29 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 810AB21F8767 for ; Wed, 2 Jan 2013 14:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=J.Renouard@f5.com; q=dns/txt; s=seattle; t=1357165709; x=1388701709; h=from:to:subject:date:message-id:mime-version; bh=hpLwSE1VhB5kEXJ2M2JnAtGcfOHguQ1aJKrXLJFJzjo=; b=KplGvcRKtMYCuvYR1WWR4xsBv3taQdaHw+i6ZEHHZcUo4F8ClZhEjMS1 P0HrtXcih639OcY1xks7XjZN4/8yqUm93FmdPdTow7kX9yQHyO9H8eysX m9060AhlDh/UZXUXzcNaZNxaHU7FuB33oYAm07s1xg5kIxJmRmhpfoA+v g=; X-IronPort-AV: E=Sophos;i="4.84,398,1355097600"; d="scan'208,217";a="59582409" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.240]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 02 Jan 2013 22:28:28 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.02.0283.003; Wed, 2 Jan 2013 14:28:27 -0800 From: Julia Renouard To: "Reinaldo Penno (repenno)" , "Senthil Sivakumar (ssenthil)" , "behave@ietf.org" Thread-Topic: Comments on draft-sivakumar-behave-nat-logging-05 Thread-Index: Ac3pM+wgT/qoVm2nTy6+PuaNjoLN5Q== Date: Wed, 2 Jan 2013 22:28:26 +0000 Message-ID: <04B0EA2BFC1C91479AD86F776659AE7530B6B81E@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.200] Content-Type: multipart/alternative; boundary="_000_04B0EA2BFC1C91479AD86F776659AE7530B6B81ESEAEMBX01olympu_" MIME-Version: 1.0 Subject: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 22:28:32 -0000 --_000_04B0EA2BFC1C91479AD86F776659AE7530B6B81ESEAEMBX01olympu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Reinaldo & Senthil - Thank you for your work here. I know this has been through a few iteration= s . I do think this is needed minimally as guidance. This was the only t= hing we found, save for section 4 in behave-lsn-requirements that gave guid= ance on CGN logging. And your justification is spot-on. Now for feedback= ... Summary: First, we are very concerned about the re-enumeration of natEvent values in= section 4.2. It is not good practice and is disruptive to implementers to= re-enumerate published values. Also the values created here are too speci= fic and make this not-easily extended. The only exception I might make h= ere is to change the existing "Pool Exhausted" value to be "Translation Fai= lure" or simply add a new enum for this. I think generic events are better= than specific. More on this below. I would like to see this draft reference and be consistent with draft-ietf-= behave-lsn-requirements-x which does describe, in section 4, logging requir= ements for a CGN. I think this document needs align with the logging requi= rements here in the overall goals and constraints. Namely, the primary goa= l for NAT logging is to enable the ability to identify a subscriber - often= for legal reasons. The constraint that we need to be mindful of is loggin= g resource consumption. Many CGN features are specifically designed to min= imize log size while still maintaining the ability to identify subscribers = - Port block allocation for example. CGN logging for the purposes of identifying subscribers and with the goal o= f minimizing data consumption, needs to focus on the NAT translations (bind= ings) and be as minimalistic as possible. Flow logging or session logging = has a different purpose - statistical, data usage analysis, quality analysi= s, security, billing... There may be some overlap of use-cases but this do= cument doesn't really speak to them. It might be interesting to look at ty= pical/traditional NetFlow/IPFIX Flow logging and see how that might be diff= erent for a NAT. But there are at least 2 different use-cases - if this d= ocument wants to address both, I think it would be useful to distinguish th= em. But flow/session logging needs to be discrete because administrators m= ay only choose translation logging for data conservation purposes. It seem= s to me that your session create/delete events fall into this camp, althoug= h I'm interested in your intent here. Minimally I'd be interested in a com= parison. My high level recommendations: 1. Don't renumber IANA defined enums. Reasons cited above. 2. Keep high level events generic. This makes them more extensible. = "Create", "Delete" and "Translation Failure" - with more data as additiona= l (optional) IE's. For example, keeping the "error" event generic allows c= ollectors to universally identify an error, even as more error types are cr= eated. 3. Be careful about error logging recommendations. I would set these= as MAY with comments about limiting how often these are emitted in a pool = exhaustion case so as not to DoS the source or target system. 4. Consider DSLite in your recommendations - what IE's should be used= to report a DSLite subscriber? 5. Make the Port Block Allocation extensions part of the "Create" and= "Delete" event templates. 6. Call out specifically which IE's are new. Section 7 is not comple= te or accurate. portRange* ID's have been defined. You also have IE's ide= ntified which do not exist and are not called out in section 7. 7. Section 4 - Event based Logging: "Each of these events SHOULD be = logged, unless they are administratively prohibited" - This is a problemati= c recommendation and is contrary to the need to minimize logging (i.e. logg= ing every session ) 8. Bring this into alignment with draft-behave-lsn-requirements. E.= g. REQ-12. Destination addresses SHOULD NOT be logged. That said, a mappin= g event MAY have a destination address if administrator requires it. In wh= ich case I would recommend only 1 IE - destinationIPxAddress or postNATDest= inationIPvxAddress - both seems redundant. 9. Separate out session logging from translation logging. Session lo= gging bloats the data set and is unnecessary just for identifying subscribe= rs 10. Describe the difference between session logging and BIB(translation) = logging and when to use them. IMHO session logging looks a lot more like f= low logging. I'd be interested in a description of the differences and a s= eparate of the two cases. Perhaps flow logging for NAT's is a separate use= -case. 11. Look at using natPoolName optionally in more events - I think it will= be useful, minimally for errors 12. Can we find an IE to send a "subscriber identity"? I'm wondering abo= ut #371, "userName" - for a mobile service provider this might actually be = an IMSI or IMEI numbers. This would be optional. 13. Be mindful of the need for data conservation and to minimize logging = in your MUST and SHOULD requirements. MUST and SHOULD requirements should = be minimalistic to achieve the base use-case and nothing more. E.g. look t= o the data elements identified in behave-lsn-requirements. But ideally it = also gives guidance on some typical use-cases and how to achieve them. One more nit: [NAT-EVENT-LOG-IANA] - this link does not exist. You shoul= d update this to be the IANA IPFIX IE registry. Thanks again for this. I hope this feedback is helpful. We look forward t= o the next draft. Happy New Year, Julia Renouard --_000_04B0EA2BFC1C91479AD86F776659AE7530B6B81ESEAEMBX01olympu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Reinaldo & Senthi= l –

 

Thank you for your work = here.  I know this has been through a few iterations .  I do thin= k this is needed minimally as guidance.   This was the only thing= we found, save for section 4 in behave-lsn-requirements that gave guidance on CGN logging.  And your justification is spot-on= .   Now for feedback…

  <= /p>

Summary:

First, we are very conce= rned about the re-enumeration of natEvent values in section 4.2.  It i= s not good practice and is disruptive to implementers to re-enumerate publi= shed values.  Also the values created here are too specific and make this not-easily extended.    The = only exception I might make here is to change the existing "Pool Exhau= sted" value to be "Translation Failure" or simply add a new = enum for this.  I think generic events are better than specific. = More on this below.

 

I would like to see this= draft reference and be consistent with draft-ietf-behave-lsn-requirements-= x which does describe, in section 4, logging requirements for a CGN.  = I think this document needs align with the logging requirements here in the overall goals and constraints.  Name= ly, the primary goal for NAT logging is to enable the ability to identify a= subscriber - often for legal reasons.  The constraint that we need to= be mindful of is logging resource consumption.  Many CGN features are specifically designed to minimize log size while sti= ll maintaining the ability to identify subscribers - Port block allocation = for example.

 

CGN logging for the purp= oses of identifying subscribers and with the goal of minimizing data consum= ption, needs to focus on the NAT translations (bindings) and be as minimali= stic as possible.  Flow logging or session logging has a different purpose - statistical, data usage analysis, qualit= y analysis, security, billing…  There may be some overlap of use= -cases but this document doesn't really speak to them.  It might be in= teresting to look at typical/traditional NetFlow/IPFIX Flow logging and see how that might be different for a NAT.   Bu= t there are at least 2 different use-cases - if this document wants to addr= ess both, I think it would be useful to distinguish them.  But flow/se= ssion logging needs to be discrete because administrators may only choose translation logging for data conservation purposes.  = It seems to me that your session create/delete events fall into this camp, = although I’m interested in your intent here.  Minimally I’= d be interested in a comparison.

 

 

My high level recommenda= tions:

1.       Don't renumber IANA defined enums.  Reasons ci= ted above. 

2.       Keep high level events generic.  This makes th= em more extensible.  "Create", "Delete" and "= Translation Failure" - with more data as additional (optional) IE's.&n= bsp; For example, keeping the "error" event generic allows collec= tors to universally identify an error, even as more error types are created.  =

3.       Be careful about error logging recommendations.&nbs= p; I would set these as MAY with comments about limiting how often these ar= e emitted in a pool exhaustion case so as not to DoS the source or target s= ystem. 

4.       Consider DSLite in your recommendations - what IE's= should be used to report a DSLite subscriber? 

5.       Make the Port Block Allocation extensions part of t= he "Create" and "Delete" event templates.

6.       Call out specifically which IE's are new.  Sec= tion 7 is not complete or accurate.  portRange* ID's have been defined= .  You also have IE's identified which do not exist and are not called= out in section 7.

7.       Section 4 - Event based Logging:  "Each o= f these events SHOULD be logged, unless they are administratively prohibite= d" - This is a problematic recommendation and is contrary to the need = to minimize logging (i.e. logging every session )

8.       Bring this into alignment with draft-behave-lsn-req= uirements.   E.g. REQ-12. Destination addresses SHOULD NOT be log= ged.  That said, a mapping event MAY have a destination address if adm= inistrator requires it.  In which case I would recommend only 1 IE - destinationIPxAddress or postNATDestinationIPvxAddre= ss - both seems redundant.

9.       Separate out session logging from translation loggi= ng.  Session logging bloats the data set and is unnecessary just for i= dentifying subscribers

10.   Describe the difference between session logging and= BIB(translation) logging and when to use them.  IMHO session logging = looks a lot more like flow logging.  I'd be interested in a descriptio= n of the differences and a separate of the two cases.  Perhaps flow logging for NAT's is a separate use-case.&nb= sp;

11.   Look at using natPoolName optionally in more events= - I think it will be useful, minimally for errors

12.   Can we find an IE to send a "subscriber identi= ty"?  I'm wondering about #371, "userName" - for a mobi= le service provider this might actually be an IMSI or IMEI numbers.  T= his would be optional.

13.   Be mindful of the need for data conservation and to= minimize logging in your MUST and SHOULD requirements.  MUST and SHOU= LD requirements should be minimalistic to achieve the base use-case and not= hing more.  E.g. look to the data elements identified in behave-lsn-requirements.  But ideally it also gives gui= dance on some typical use-cases and how to achieve them.

 

 

One more nit:   [NAT-EVENT-LOG-IANA] - thi= s link does not exist.  You should update this to be the IANA IPFIX IE= registry.

 

 

Thanks again for this.  I hope this feedback is= helpful.  We look forward to the next draft.

 

Happy New Year,

 

Julia Renouard

--_000_04B0EA2BFC1C91479AD86F776659AE7530B6B81ESEAEMBX01olympu_-- From ssenthil@cisco.com Wed Jan 2 16:13:51 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA14921F86DD for ; Wed, 2 Jan 2013 16:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.336 X-Spam-Level: X-Spam-Status: No, score=-10.336 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE+EA0U6-k0C for ; Wed, 2 Jan 2013 16:13:50 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B537E21F888E for ; Wed, 2 Jan 2013 16:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46636; q=dns/txt; s=iport; t=1357172029; x=1358381629; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=3uTmkjLRiYoMHymu9/+/cENzxcl+ODtkhbgdfqXY3+I=; b=GLHkflHXkFMjF0zSO/OYSV/10XClt9d/Kmo08Mdbz7/jJp8+N00qOfiN e8CaS5Z1+TYd53jF82XinFysdoWiZsD6YAL+CrAfzrdonjfXP3LRkrkk+ 1LtHMmEkcMZf/ZWTycvnx4KZ1hwkH8R5KTeAmlEqdp8FitnfogYQWHL/G Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAK3M5FCtJXG8/2dsb2JhbAA7AQmBf0q6fBZzgh4BAQEELV4BCA4DAwECCxYBBjkUCQgBAQQBEAIIE4d4t3mMaAGDUGEDplSCdEGBZQ X-IronPort-AV: E=Sophos;i="4.84,398,1355097600"; d="scan'208,217";a="158283049" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 03 Jan 2013 00:13:36 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r030DaOT026987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Jan 2013 00:13:36 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.156]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 2 Jan 2013 18:13:36 -0600 From: "Senthil Sivakumar (ssenthil)" To: Julia Renouard , "Reinaldo Penno (repenno)" , "behave@ietf.org" Thread-Topic: Comments on draft-sivakumar-behave-nat-logging-05 Thread-Index: Ac3pM+wgT/qoVm2nTy6+PuaNjoLN5QAG6DQA Date: Thu, 3 Jan 2013 00:13:35 +0000 Message-ID: In-Reply-To: <04B0EA2BFC1C91479AD86F776659AE7530B6B81E@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.117.198.136] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D0232334B53xmbrcdx15ciscoc_" MIME-Version: 1.0 Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 00:13:51 -0000 --_000_CB1B483277FEC94E9B58357040EE5D0232334B53xmbrcdx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Julia, Thanks for the comments. Please see inline. From: Julia Renouard > Date: Wednesday, January 2, 2013 5:28 PM To: "Reinaldo Penno (repenno)" = >, Senthil Sivakumar >, "beha= ve@ietf.org" > Subject: Comments on draft-sivakumar-behave-nat-logging-05 Hi Reinaldo & Senthil =96 Thank you for your work here. I know this has been through a few iteration= s . I do think this is needed minimally as guidance. This was the only t= hing we found, save for section 4 in behave-lsn-requirements that gave guid= ance on CGN logging. And your justification is spot-on. Now for feedback= =85 Summary: First, we are very concerned about the re-enumeration of natEvent values in= section 4.2. It is not good practice and is disruptive to implementers to= re-enumerate published values. Also the values created here are too speci= fic and make this not-easily extended. The only exception I might make h= ere is to change the existing "Pool Exhausted" value to be "Translation Fai= lure" or simply add a new enum for this. I think generic events are better= than specific. More on this below. [Senthil] I assume you mean the IPFIX IANA assigned values for natEvents. Y= ou are right, there is an inconsistency between the two. As you pointed out= , the create and delete event is consistent with the IPFIX values, we need = to add the poolExhausted value in the draft or create a new value for it. = We will do it as part of the next rev. I would like to see this draft reference and be consistent with draft-ietf-= behave-lsn-requirements-x which does describe, in section 4, logging requir= ements for a CGN. I think this document needs align with the logging requi= rements here in the overall goals and constraints. Namely, the primary goa= l for NAT logging is to enable the ability to identify a subscriber - often= for legal reasons. The constraint that we need to be mindful of is loggin= g resource consumption. Many CGN features are specifically designed to min= imize log size while still maintaining the ability to identify subscribers = - Port block allocation for example. [Senthil] This document is not just for CGN logging, it is a generic NAT lo= gging document that can be used also for satisfying CGN logging requirement= s. As mentioned in the scope, the optimization of log events (size, the way= you pack the records etc) is not within the scope of this document. There = are many other documents that provide solutions for that. The main purpose = of this document is to provide a framework and a template to log NAT events= =96 that both the NAT vendors and the collector vendors can use to interop= erate. CGN logging for the purposes of identifying subscribers and with the goal o= f minimizing data consumption, needs to focus on the NAT translations (bind= ings) and be as minimalistic as possible. Flow logging or session logging = has a different purpose - statistical, data usage analysis, quality analysi= s, security, billing=85 There may be some overlap of use-cases but this do= cument doesn't really speak to them. It might be interesting to look at ty= pical/traditional NetFlow/IPFIX Flow logging and see how that might be diff= erent for a NAT. But there are at least 2 different use-cases - if this d= ocument wants to address both, I think it would be useful to distinguish th= em. But flow/session logging needs to be discrete because administrators m= ay only choose translation logging for data conservation purposes. It seem= s to me that your session create/delete events fall into this camp, althoug= h I=92m interested in your intent here. Minimally I=92d be interested in a= comparison. [Senthil] Just to re-iterate, the focus of the draft is generic NAT logging= =96 not just CGN. The NAT templates defined in the draft is generic enough= to cover both CGN and non-CGN NAT logging. I am not really sure I understa= nd the gist of the above paragraph, but flow logging is being used for data= retention purposes. Again our intention here is have a generic logging fra= mework. My high level recommendations: 1. Don't renumber IANA defined enums. Reasons cited above. [Senthil] Ok. But a lot of what is defined here is what went on to become I= ANA values, but your point is well taken, we will get rid of inconsistencie= s. 2. Keep high level events generic. This makes them more extensible. = "Create", "Delete" and "Translation Failure" - with more data as additiona= l (optional) IE's. For example, keeping the "error" event generic allows c= ollectors to universally identify an error, even as more error types are cr= eated. [Senthil] The problem is if we have a simple create, delete, we wont be abl= e to distinguish what kind of an nat this is =96 nat44, nat64 etc. For us t= o add additional data, that would cause us to have another byte. In this ca= se, we can have a max of 256 types (with 8 bits) and hence make sense to pr= esent the information in one shot. I am open to suggestions here but would = like some WG guidance. 3. Be careful about error logging recommendations. I would set these= as MAY with comments about limiting how often these are emitted in a pool = exhaustion case so as not to DoS the source or target system. [Senthil] Agreed. 4. Consider DSLite in your recommendations - what IE's should be used= to report a DSLite subscriber? [Senthil] We had DS lite in earlier revision of the draft in -03. But the W= G wanted us to keep it specifically to NAT, so the latest versions got rid = of them. 5. Make the Port Block Allocation extensions part of the "Create" and= "Delete" event templates. [Senthil] Ok. 6. Call out specifically which IE's are new. Section 7 is not comple= te or accurate. portRange* ID's have been defined. You also have IE's ide= ntified which do not exist and are not called out in section 7. [Senthil] Ok. 7. Section 4 - Event based Logging: "Each of these events SHOULD be = logged, unless they are administratively prohibited" - This is a problemati= c recommendation and is contrary to the need to minimize logging (i.e. logg= ing every session ) [Senthil] As I clarified above, minimizing logging is not a goal of this dr= aft. 8. Bring this into alignment with draft-behave-lsn-requirements. E.= g. REQ-12. Destination addresses SHOULD NOT be logged. That said, a mappin= g event MAY have a destination address if administrator requires it. In wh= ich case I would recommend only 1 IE - destinationIPxAddress or postNATDest= inationIPvxAddress - both seems redundant. [Senthil] I think we can add some text around this, that if the CGN is runn= ing, then destination address should not be logged. 9. Separate out session logging from translation logging. Session lo= gging bloats the data set and is unnecessary just for identifying subscribe= rs 10. Describe the difference between session logging and BIB(translation) = logging and when to use them. IMHO session logging looks a lot more like f= low logging. I'd be interested in a description of the differences and a s= eparate of the two cases. Perhaps flow logging for NAT's is a separate use= -case. [Senthil] As explained above, for 9 & 10, this is a generic draft. 11. Look at using natPoolName optionally in more events - I think it will= be useful, minimally for errors [Senthil] Ok. 12. Can we find an IE to send a "subscriber identity"? I'm wondering abo= ut #371, "userName" - for a mobile service provider this might actually be = an IMSI or IMEI numbers. This would be optional. [Senthil] I will check, the last time I checked there were a couple of fiel= ds that could be used. 13. Be mindful of the need for data conservation and to minimize logging = in your MUST and SHOULD requirements. MUST and SHOULD requirements should = be minimalistic to achieve the base use-case and nothing more. E.g. look t= o the data elements identified in behave-lsn-requirements. But ideally it = also gives guidance on some typical use-cases and how to achieve them. [Senthil] Minimizing the logging is not the goal of this draft. One more nit: [NAT-EVENT-LOG-IANA] - this link does not exist. You shoul= d update this to be the IANA IPFIX IE registry. [Senthil] Ok, thanks. Thanks again for this. I hope this feedback is helpful. We look forward t= o the next draft. [Senthil] Thanks for the helpful comments. Will incorporate the relevant on= es. Senthil Happy New Year, Julia Renouard --_000_CB1B483277FEC94E9B58357040EE5D0232334B53xmbrcdx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Julia,
Thanks for the comments. Please see inline.

From: Julia Renouard <J.Renouard@F5.com>
Date: Wednesday, January 2, 2013 5:= 28 PM
To: "Reinaldo Penno (repenno)&= quot; <repenno@cisco.com>, S= enthil Sivakumar <ssenthil@cisco.c= om>, "behave@ietf.org&qu= ot; <behave@ietf.org>
Subject: Comments on draft-sivakuma= r-behave-nat-logging-05

Hi Reinaldo & Senthi= l =96

 

Thank you for your work = here.  I know this has been through a few iterations .  I do thin= k this is needed minimally as guidance.   This was the only thing= we found, save for section 4 in behave-lsn-requirements that gave guidance on CGN logging.  And your justification is spot-on= .   Now for feedback=85

  <= /p>

Summary:

First, we are very conce= rned about the re-enumeration of natEvent values in section 4.2.  It i= s not good practice and is disruptive to implementers to re-enumerate publi= shed values.  Also the values created here are too specific and make this not-easily extended.    The = only exception I might make here is to change the existing "Pool Exhau= sted" value to be "Translation Failure" or simply add a new = enum for this.  I think generic events are better than specific. = More on this below.

[Senthil] I assume you mean the IPFIX IANA assigned values for natEven= ts. You are right, there is an inconsistency between the two. As you pointe= d out, the create and delete event is consistent with the IPFIX values, we = need to add the poolExhausted value in the draft or create a new value for it.  We will do it as part of = the next rev. 

 

I would like to see this= draft reference and be consistent with draft-ietf-behave-lsn-requirements-= x which does describe, in section 4, logging requirements for a CGN.  = I think this document needs align with the logging requirements here in the overall goals and constraints.  Name= ly, the primary goal for NAT logging is to enable the ability to identify a= subscriber - often for legal reasons.  The constraint that we need to= be mindful of is logging resource consumption.  Many CGN features are specifically designed to minimize log size while sti= ll maintaining the ability to identify subscribers - Port block allocation = for example.

[Senthil] This document is not just for CGN logging, it is a generic N= AT logging document that can be used also for satisfying CGN logging requir= ements. As mentioned in the scope, the optimization of log events (size, th= e way you pack the records etc) is not within the scope of this document. There are many other documents t= hat provide solutions for that. The main purpose of this document is to pro= vide a framework and a template to log NAT events =96 that both the NAT ven= dors and the collector vendors can use to interoperate.

 

CGN logging for the purp= oses of identifying subscribers and with the goal of minimizing data consum= ption, needs to focus on the NAT translations (bindings) and be as minimali= stic as possible.  Flow logging or session logging has a different purpose - statistical, data usage analysis, qualit= y analysis, security, billing=85  There may be some overlap of use-cas= es but this document doesn't really speak to them.  It might be intere= sting to look at typical/traditional NetFlow/IPFIX Flow logging and see how that might be different for a NAT.   Bu= t there are at least 2 different use-cases - if this document wants to addr= ess both, I think it would be useful to distinguish them.  But flow/se= ssion logging needs to be discrete because administrators may only choose translation logging for data conservation purposes.  = It seems to me that your session create/delete events fall into this camp, = although I=92m interested in your intent here.  Minimally I=92d be int= erested in a comparison.

[Senthil] Just to re-iterate, the focus of the draft is generic NAT lo= gging =96 not just CGN. The NAT templates defined in the draft is generic e= nough to cover both CGN and non-CGN NAT logging. I am not really sure I und= erstand the gist of the above paragraph, but flow logging is being used for data retention purposes. Again our inte= ntion here is have a generic logging framework. 
 

 

My high level recommenda= tions:

1.   = ;    Don't renumber IANA defined enums.  Reason= s cited above. 

[Senthil] Ok. But a lot of what is defined here is what went on to bec= ome IANA values, but your point is well taken, we will get rid of inconsist= encies.

2.   = ;    Keep high level events generic.  This make= s them more extensible.  "Create", "Delete" and &q= uot;Translation Failure" - with more data as additional (optional) IE'= s.  For example, keeping the "error" event generic allows co= llectors to universally identify an error, even as more error types are created. =

[Senthil] The problem is if we have a simple create, delete, we wont b= e able to distinguish what kind of an nat this is =96 nat44, nat64 etc. For= us to add additional data, that would cause us to have another byte. In th= is case, we can have a max of 256 types (with 8 bits) and hence make sense to present the information in one= shot. I am open to suggestions here but would like some WG guidance.

3.   = ;    Be careful about error logging recommendations.=   I would set these as MAY with comments about limiting how often thes= e are emitted in a pool exhaustion case so as not to DoS the source or targ= et system. 
[Senthil] Agreed. 

4.   = ;    Consider DSLite in your recommendations - what = IE's should be used to report a DSLite subscriber? 

[Senthil] We had DS lite in earlier revision of the draft in -03. But = the WG wanted us to keep it specifically to NAT, so the latest versions got= rid of them.

5.   = ;    Make the Port Block Allocation extensions part = of the "Create" and "Delete" event templates.
[Senthil] Ok.

6.   = ;    Call out specifically which IE's are new. = Section 7 is not complete or accurate.  portRange* ID's have been def= ined.  You also have IE's identified which do not exist and are not ca= lled out in section 7.
[Senthil] Ok.

7.   = ;    Section 4 - Event based Logging:  "Ea= ch of these events SHOULD be logged, unless they are administratively prohi= bited" - This is a problematic recommendation and is contrary to the n= eed to minimize logging (i.e. logging every session )
[Senthil] As I clarified above, minimizing logging is not a goal of th= is draft.

8.   = ;    Bring this into alignment with draft-behave-lsn= -requirements.   E.g. REQ-12. Destination addresses SHOULD NOT be= logged.  That said, a mapping event MAY have a destination address if= administrator requires it.  In which case I would recommend only 1 IE - destinationIPxAddress or postNATDestinationIPvxAddre= ss - both seems redundant.
[Senthil] I think we can add some text around this, that if the CGN is= running, then destination address should not be logged.

9.   = ;    Separate out session logging from translation l= ogging.  Session logging bloats the data set and is unnecessary just f= or identifying subscribers


10.   Describe the difference between session logging= and BIB(translation) logging and when to use them.  IMHO session logg= ing looks a lot more like flow logging.  I'd be interested in a descri= ption of the differences and a separate of the two cases.  Perhaps flow logging for NAT's is a separate use-case= . 
[Senthil] As explained above, for 9 & 10, this is a generic draft.=

11.   Look at using natPoolName optionally in more ev= ents - I think it will be useful, minimally for errors

[Senthil] Ok.

12.   Can we find an IE to send a "subscriber id= entity"?  I'm wondering about #371, "userName" - for a = mobile service provider this might actually be an IMSI or IMEI numbers.&nbs= p; This would be optional.
[Senthil] I will check, the last time I checked there were a couple of= fields that could be used.  

13.   Be mindful of the need for data conservation an= d to minimize logging in your MUST and SHOULD requirements.  MUST and = SHOULD requirements should be minimalistic to achieve the base use-case and= nothing more.  E.g. look to the data elements identified in behave-lsn-requirements.  But ideally it also = gives guidance on some typical use-cases and how to achieve them.

[Senthil] Minimizing the logging is not the goal of this draft.

 

 

One more nit:   [NAT-EVENT-LOG-IANA] - thi= s link does not exist.  You should update this to be the IANA IPFIX IE= registry.

[Senthil] Ok, thanks.

 

 

Thanks again for this.  I hope this feedback is= helpful.  We look forward to the next draft.

 
[Senthil] Thanks for the helpful comments. Will incorporate the releva= nt ones.

Senthil

Happy New Year,

 

Julia Renouard

 --_000_CB1B483277FEC94E9B58357040EE5D0232334B53xmbrcdx15ciscoc_-- From J.Renouard@F5.com Wed Jan 2 17:04:03 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CF221F8881 for ; Wed, 2 Jan 2013 17:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.133 X-Spam-Level: X-Spam-Status: No, score=-10.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-y8eqlwpEtI for ; Wed, 2 Jan 2013 17:04:01 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id A6B9121F8831 for ; Wed, 2 Jan 2013 17:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=J.Renouard@f5.com; q=dns/txt; s=seattle; t=1357175041; x=1388711041; h=from:to:subject:date:message-id:mime-version; bh=f3+rpAeIuarZWWdI2zrqKKHtyF3AEE5Xp2/Bq3Z7CZY=; b=X1Css0c29VNbmh1quijD+sF1QJWUGnlL5wXJK9RXSm1kqRMwwTxebRY/ w+GobzkcP/tWw3J8uOEaD3AqlnjNHw18l1/Y2ppNKCvlR7ECyNUoHEBvl QgT549HXhtErASkCb4CmZ4eIQCLhiJxeJVcQeV1yCeC+f3RpDUqxm9Unz U=; X-IronPort-AV: E=Sophos;i="4.84,400,1355097600"; d="scan'208,217";a="60083866" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.240]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 03 Jan 2013 01:04:00 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.02.0283.003; Wed, 2 Jan 2013 17:04:00 -0800 From: Julia Renouard To: "simon.perreault@viagenie.ca" , "behave@ietf.org" Thread-Topic: Review of draft-ietf-behave-nat-mib-03 Thread-Index: Ac3pTF/g+e9HOtSQQCyWGCJEwQn+Wg== Date: Thu, 3 Jan 2013 01:03:59 +0000 Message-ID: <04B0EA2BFC1C91479AD86F776659AE7530B6C5C2@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: multipart/alternative; boundary="_000_04B0EA2BFC1C91479AD86F776659AE7530B6C5C2SEAEMBX01olympu_" MIME-Version: 1.0 Subject: [BEHAVE] Review of draft-ietf-behave-nat-mib-03 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 01:04:03 -0000 --_000_04B0EA2BFC1C91479AD86F776659AE7530B6C5C2SEAEMBX01olympu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Simon - I'm finally getting back to your request for review. Overall I think this is a good update to 4008. High level feedback here (= and part of what's taken so long to try and get feedback) - it would be hel= pful if this were reformatted to be clearer. It is really hard to clearly = identify which objects have been deprecated and which are current or new. = I was spending so much time with my red pen and highlighter, that I was una= ble to give it the concentrated time it needs. So I thought I'd just give = you this feedback to start. First - kudos: I very much appreciate the drive to move away from writable= elements and away from elements that imply internal designs. As you corre= ctly observe, implementations vary widely. The MIB should not make assumpt= ions about internal designs and should only expose elements in an abstracte= d view and are commonly understood and implemented by all NATs. This is gr= eat. Some suggestions: In Section 3 you briefly summarize the deprecated and new features, but I'd= love to see this extended to discuss the tables and top level new, changed= and deprecated objects along with justifications. I also wonder if it's p= ossible to discuss the current and new elements alone in their own sections= . It is also quite unclear without doing a diff of 4008 which elements hav= e simply changed -e.g. removed writeability. You can still present a cohe= rent MIB including the deprecated elements, in a later section. But this w= ould make it much easier to read, review and implement. If syntactically = legal, it might be nice to also publish the reduced MIB of just the current= elements (w/o the deprecated ones). Please also call out specific categories of objects as in 4008 section 4. = This makes it easier to find what you're looking for. I'm still wanting to review it for content. I will continue to do so but = I wanted to get you something in the meantime. Regards, Julia Renouard --_000_04B0EA2BFC1C91479AD86F776659AE7530B6C5C2SEAEMBX01olympu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Simon –=  I’m finally getting back to your request for review.

 

Overall I think = this is a good update to 4008.   High level feedback here (and pa= rt of what's taken so long to try and get feedback) - it would be helpful if this were reformatted to be clearer.  It is really hard to= clearly identify which objects have been deprecated and which are current = or new.  I was spending so much time with my red pen and highlighter, = that I was unable to give it the concentrated time it needs.  So I thought I'd just give you this feedback to start= .

 

First - kudos:&n= bsp; I very much appreciate the drive to move away from writable elements a= nd away from elements that imply internal designs.  As you correctly observe, implementations vary widely.  The MIB should not make assump= tions about internal designs and should only expose elements in an abstract= ed view and are commonly understood and implemented by all NATs.  This= is great.

 

Some suggestions= :

In Section 3 you= briefly summarize the deprecated and new features, but I'd love to see thi= s extended to discuss the tables and top level new, changed and deprecated objects along with justifications.  I also wonder if i= t’s possible to discuss the current and new elements alone in their o= wn sections.  It is also quite unclear without doing a diff of 4008 wh= ich elements have simply changed –e.g. removed writeability.   You can still present a coherent MIB including the deprecated elemen= ts, in a later section.  But this would make it much easier to read, r= eview and implement.   If syntactically legal, it might be nice t= o also publish the reduced MIB of just the current elements (w/o the deprecated ones). 

 

Please also call= out specific categories of objects as in 4008 section 4.  This makes = it easier to find what you're looking for.

 

I'm still wantin= g to review it for content.   I will continue to do so but I want= ed to get you something in the meantime.

 

Regards,

Julia Renouard

 

 

--_000_04B0EA2BFC1C91479AD86F776659AE7530B6C5C2SEAEMBX01olympu_-- From J.Renouard@F5.com Wed Jan 2 18:05:36 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084F721F874F for ; Wed, 2 Jan 2013 18:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.288 X-Spam-Level: X-Spam-Status: No, score=-10.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhwwBPEWW9aM for ; Wed, 2 Jan 2013 18:05:29 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id BAF8321F85CC for ; Wed, 2 Jan 2013 18:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=J.Renouard@f5.com; q=dns/txt; s=seattle; t=1357178728; x=1388714728; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=f8J8ILck4oMHMHrxD7w9gi3khVPYo3Jdyl0PMFbCjpU=; b=ntECSwS983PnFv1j8i1WhC+Y0NnUqXndXXQuik015sh0Z9ou8Cx+0lo/ J4qaeDlqEp8gvGXjtNmE9VcQ8uwtSrmvFPP/42ToO9RHZCG6Y57naetcR g3nB8IMEeUDFnq8ktk+xtOGbDY5w6821yflzdUZGbCf9DJGq1/cWYIvGy U=; X-IronPort-AV: E=Sophos;i="4.84,400,1355097600"; d="scan'208,217";a="59592819" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.240]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 03 Jan 2013 02:05:26 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.02.0283.003; Wed, 2 Jan 2013 18:05:26 -0800 From: Julia Renouard To: "Senthil Sivakumar (ssenthil)" , "Reinaldo Penno (repenno)" , "behave@ietf.org" Thread-Topic: Comments on draft-sivakumar-behave-nat-logging-05 Thread-Index: Ac3pM+wgT/qoVm2nTy6+PuaNjoLN5QAG6DQAAAApXdA= Date: Thu, 3 Jan 2013 02:05:25 +0000 Message-ID: <04B0EA2BFC1C91479AD86F776659AE7530B6C63E@SEAEMBX01.olympus.F5Net.com> References: <04B0EA2BFC1C91479AD86F776659AE7530B6B81E@SEAEMBX01.olympus.F5Net.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: multipart/alternative; boundary="_000_04B0EA2BFC1C91479AD86F776659AE7530B6C63ESEAEMBX01olympu_" MIME-Version: 1.0 Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 02:05:36 -0000 --_000_04B0EA2BFC1C91479AD86F776659AE7530B6C63ESEAEMBX01olympu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Senthil - Nice fast turn-around. So part of my confusion here appears t= o be derived from your opening sentence in the Abstract and Scope sections:= "This document provides the information model to be used for logging the= Carrier Grade NAT (CGN) events." So you might want to clarify the scope = as well if this is intended to be broader than CGN. :) My apologies that = I did not review the history of this draft. I started with this for review= - a bit in a vacuum I admit. A follow up thought, if this is intended to be for all NAT types, including= generic NAT and CGN, not paying attention to minimizing logging and the ba= ndwidth and data constraints of the CGN deployments will end up making most= CGN devices to only be partially compliant if the recommendations laid out= here remain a SHOULD or do not take this need into account. We will simpl= y have to use it as high-level guidance and take our own path because minim= izing logging is a requirement for us. Even so, I think it will still be u= seful to identify the common use-cases for logging. This helps better revi= ew if the recommendations you are making achieve those goals or not. On the question of the generic vs specific natEvent enumerations, I actuall= y feel the generic is more extensible, but yes, I agree - broader WG opinio= ns should be sought and to be honest I have not compared it with other IE's= for consistency nor looked at IPFIX collector implementations. My concern= is as much from a "best practice" of data hiding - where events are generi= c and type is part of data. This facilitates extensibility and future proo= fing implementations. The example of the error enumeration is a good one. = As a collector, I can implement to recognize a generic "Translation error= " event - and I don't need to update my software for every new error type t= hat comes along. I know I will catch it. I may not know what type of erro= r but I will know an error occurred. As for the generic NAT events vs. spe= cific type-encoded events, yes I understand the goal of having the nat type= . You could provide the additional natType IE in the template but, as you = say, that is an additional byte. However IMHO the value of extensibility o= utweighs this. In order to add NAT66, for example, you now need to extend = this yet again. Not having implemented an IPFIX collector I cannot speak= to whether this addition of the NAT type actually resolves any ambiguity t= hat the different templates would not. (sourceIPv6Address vs. IPv4). I'd have to look back in the threads for the feedback on DS-Lite to underst= and the concerns wrt this draft, but as an implementer it is something I ha= ve to solve. I don't think it requires any new types. But I think it woul= d be useful to offer template guidance. For us, we were intending simply t= o use a sourceIPv6Address IE (consistent with Section 4 in behave-lsn-requi= rements). Optionally we may also include a sourceIPv4Address if the custom= er desired. Again, I don't think it needs its own IE's or types, just temp= late guidance and how this will be interpreted commonly by collectors. Jus= t a thought... Thanks again - we look forward to the next round. I appreciate your work h= ere, Julia From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] Sent: Wednesday, January 02, 2013 4:14 PM To: Julia Renouard; Reinaldo Penno (repenno); behave@ietf.org Subject: Re: Comments on draft-sivakumar-behave-nat-logging-05 Hi Julia, Thanks for the comments. Please see inline. From: Julia Renouard > Date: Wednesday, January 2, 2013 5:28 PM To: "Reinaldo Penno (repenno)" = >, Senthil Sivakumar >, "beha= ve@ietf.org" > Subject: Comments on draft-sivakumar-behave-nat-logging-05 Hi Reinaldo & Senthil - Thank you for your work here. I know this has been through a few iteration= s . I do think this is needed minimally as guidance. This was the only t= hing we found, save for section 4 in behave-lsn-requirements that gave guid= ance on CGN logging. And your justification is spot-on. Now for feedback= ... Summary: First, we are very concerned about the re-enumeration of natEvent values in= section 4.2. It is not good practice and is disruptive to implementers to= re-enumerate published values. Also the values created here are too speci= fic and make this not-easily extended. The only exception I might make h= ere is to change the existing "Pool Exhausted" value to be "Translation Fai= lure" or simply add a new enum for this. I think generic events are better= than specific. More on this below. [Senthil] I assume you mean the IPFIX IANA assigned values for natEvents. Y= ou are right, there is an inconsistency between the two. As you pointed out= , the create and delete event is consistent with the IPFIX values, we need = to add the poolExhausted value in the draft or create a new value for it. = We will do it as part of the next rev. I would like to see this draft reference and be consistent with draft-ietf-= behave-lsn-requirements-x which does describe, in section 4, logging requir= ements for a CGN. I think this document needs align with the logging requi= rements here in the overall goals and constraints. Namely, the primary goa= l for NAT logging is to enable the ability to identify a subscriber - often= for legal reasons. The constraint that we need to be mindful of is loggin= g resource consumption. Many CGN features are specifically designed to min= imize log size while still maintaining the ability to identify subscribers = - Port block allocation for example. [Senthil] This document is not just for CGN logging, it is a generic NAT lo= gging document that can be used also for satisfying CGN logging requirement= s. As mentioned in the scope, the optimization of log events (size, the way= you pack the records etc) is not within the scope of this document. There = are many other documents that provide solutions for that. The main purpose = of this document is to provide a framework and a template to log NAT events= - that both the NAT vendors and the collector vendors can use to interoper= ate. CGN logging for the purposes of identifying subscribers and with the goal o= f minimizing data consumption, needs to focus on the NAT translations (bind= ings) and be as minimalistic as possible. Flow logging or session logging = has a different purpose - statistical, data usage analysis, quality analysi= s, security, billing... There may be some overlap of use-cases but this do= cument doesn't really speak to them. It might be interesting to look at ty= pical/traditional NetFlow/IPFIX Flow logging and see how that might be diff= erent for a NAT. But there are at least 2 different use-cases - if this d= ocument wants to address both, I think it would be useful to distinguish th= em. But flow/session logging needs to be discrete because administrators m= ay only choose translation logging for data conservation purposes. It seem= s to me that your session create/delete events fall into this camp, althoug= h I'm interested in your intent here. Minimally I'd be interested in a com= parison. [Senthil] Just to re-iterate, the focus of the draft is generic NAT logging= - not just CGN. The NAT templates defined in the draft is generic enough t= o cover both CGN and non-CGN NAT logging. I am not really sure I understand= the gist of the above paragraph, but flow logging is being used for data r= etention purposes. Again our intention here is have a generic logging frame= work. My high level recommendations: 1. Don't renumber IANA defined enums. Reasons cited above. [Senthil] Ok. But a lot of what is defined here is what went on to become I= ANA values, but your point is well taken, we will get rid of inconsistencie= s. 2. Keep high level events generic. This makes them more extensible. = "Create", "Delete" and "Translation Failure" - with more data as additiona= l (optional) IE's. For example, keeping the "error" event generic allows c= ollectors to universally identify an error, even as more error types are cr= eated. [Senthil] The problem is if we have a simple create, delete, we wont be abl= e to distinguish what kind of an nat this is - nat44, nat64 etc. For us to = add additional data, that would cause us to have another byte. In this case= , we can have a max of 256 types (with 8 bits) and hence make sense to pres= ent the information in one shot. I am open to suggestions here but would li= ke some WG guidance. 3. Be careful about error logging recommendations. I would set these= as MAY with comments about limiting how often these are emitted in a pool = exhaustion case so as not to DoS the source or target system. [Senthil] Agreed. 4. Consider DSLite in your recommendations - what IE's should be used= to report a DSLite subscriber? [Senthil] We had DS lite in earlier revision of the draft in -03. But the W= G wanted us to keep it specifically to NAT, so the latest versions got rid = of them. 5. Make the Port Block Allocation extensions part of the "Create" and= "Delete" event templates. [Senthil] Ok. 6. Call out specifically which IE's are new. Section 7 is not comple= te or accurate. portRange* ID's have been defined. You also have IE's ide= ntified which do not exist and are not called out in section 7. [Senthil] Ok. 7. Section 4 - Event based Logging: "Each of these events SHOULD be = logged, unless they are administratively prohibited" - This is a problemati= c recommendation and is contrary to the need to minimize logging (i.e. logg= ing every session ) [Senthil] As I clarified above, minimizing logging is not a goal of this dr= aft. 8. Bring this into alignment with draft-behave-lsn-requirements. E.= g. REQ-12. Destination addresses SHOULD NOT be logged. That said, a mappin= g event MAY have a destination address if administrator requires it. In wh= ich case I would recommend only 1 IE - destinationIPxAddress or postNATDest= inationIPvxAddress - both seems redundant. [Senthil] I think we can add some text around this, that if the CGN is runn= ing, then destination address should not be logged. 9. Separate out session logging from translation logging. Session lo= gging bloats the data set and is unnecessary just for identifying subscribe= rs 10. Describe the difference between session logging and BIB(translation) = logging and when to use them. IMHO session logging looks a lot more like f= low logging. I'd be interested in a description of the differences and a s= eparate of the two cases. Perhaps flow logging for NAT's is a separate use= -case. [Senthil] As explained above, for 9 & 10, this is a generic draft. 11. Look at using natPoolName optionally in more events - I think it will= be useful, minimally for errors [Senthil] Ok. 12. Can we find an IE to send a "subscriber identity"? I'm wondering abo= ut #371, "userName" - for a mobile service provider this might actually be = an IMSI or IMEI numbers. This would be optional. [Senthil] I will check, the last time I checked there were a couple of fiel= ds that could be used. 13. Be mindful of the need for data conservation and to minimize logging = in your MUST and SHOULD requirements. MUST and SHOULD requirements should = be minimalistic to achieve the base use-case and nothing more. E.g. look t= o the data elements identified in behave-lsn-requirements. But ideally it = also gives guidance on some typical use-cases and how to achieve them. [Senthil] Minimizing the logging is not the goal of this draft. One more nit: [NAT-EVENT-LOG-IANA] - this link does not exist. You shoul= d update this to be the IANA IPFIX IE registry. [Senthil] Ok, thanks. Thanks again for this. I hope this feedback is helpful. We look forward t= o the next draft. [Senthil] Thanks for the helpful comments. Will incorporate the relevant on= es. Senthil Happy New Year, Julia Renouard --_000_04B0EA2BFC1C91479AD86F776659AE7530B6C63ESEAEMBX01olympu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Senthil – Nic= e fast turn-around.  So part of my confusion here appears to be derive= d from your opening sentence in the Abstract and Scope sections:  &nbs= p;“This document provides the information model to be used for logging the Carrier Grade NAT (CGN) events.”   So you = might want to clarify the scope as well if this is intended to be broader t= han CGN.  J  My apologies that I did not review the history= of this draft.  I started with this for review – a bit in a vac= uum I admit.

 

A follow up thought, i= f this is intended to be for all NAT types, including generic NAT and CGN, = not paying attention to minimizing logging and the bandwidth and data const= raints of the CGN deployments will end up making most CGN devices to only be partially compliant if the recommend= ations laid out here remain a SHOULD or do not take this need into account.=   We will simply have to use it as high-level guidance and take our ow= n path because minimizing logging is a requirement for us.  Even so, I think it will still be useful to id= entify the common use-cases for logging.  This helps better review if = the recommendations you are making achieve those goals or not.

 

On the question of the= generic vs specific natEvent enumerations, I actually feel the generic is = more extensible, but yes, I agree – broader WG opinions should be sou= ght and to be honest I have not compared it with other IE’s for consistency nor looked at IPFIX collector implem= entations.  My concern is as much from a “best practice” o= f data hiding – where events are generic and type is part of data.&nb= sp; This facilitates extensibility and future proofing implementations.  The example of the error enumeration is a good one.  As a colle= ctor, I can implement to recognize a generic  “Translation error= ” event – and I don’t need to update my software for ever= y new error type that comes along.  I know I will catch it.  I ma= y not know what type of error but I will know an error occurred.  As for th= e generic NAT events vs. specific type-encoded events, yes I understand the= goal of having the nat type.  You could provide the additional natTyp= e IE in the template but, as you say, that is an additional byte.  However IMHO the value of extensibility outwe= ighs this.  In order to add NAT66, for example, you now need to extend= this yet again.    Not having implemented an IPFIX collecto= r I cannot speak to whether this addition of the NAT type actually resolves any ambiguity that the different templates would not.&nb= sp; (sourceIPv6Address vs. IPv4).    

 

I’d have to look= back in the threads for the feedback on DS-Lite to understand the concerns= wrt this draft, but as an implementer it is something I have to solve.&nbs= p; I don’t think it requires any new types.  But I think it would be useful to offer template guidance.  For us, we we= re intending simply to use a sourceIPv6Address IE (consistent with Section = 4 in behave-lsn-requirements).  Optionally we may also include a sourc= eIPv4Address if the customer desired.  Again, I don’t think it needs its own IE’s or types, just template gu= idance and how this will be interpreted commonly by collectors.  Just = a thought…

 

Thanks again – w= e look forward to the next round.  I appreciate your work here,

Julia

 

 

From: Senthil = Sivakumar (ssenthil) [mailto:ssenthil@cisco.com]
Sent: Wednesday, January 02, 2013 4:14 PM
To: Julia Renouard; Reinaldo Penno (repenno); behave@ietf.org
Subject: Re: Comments on draft-sivakumar-behave-nat-logging-05 =

 

Hi Juli= a,

Thanks = for the comments. Please see inline.

&n= bsp;

From: Julia Renouard <J.Renouard@F5.com>
Date: Wednesday, January 2, 2013 5:28 PM
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>, Senthil Sivakumar <ssenthil@cisco.com>, "behave@ietf.org" <behave@ietf.org>
Subject: Comments on draft-sivakumar-behave-nat-logging-05

&n= bsp;

Hi Reinaldo & Senthil –

 

Thank you for your work here.  I know this has been through a few = iterations .  I do think this is needed minimally as guidance. &n= bsp; This was the only thing we found, save for section 4 in behave-lsn-requirements that gave guidance on CGN logging.  And yo= ur justification is spot-on.   Now for feedback…=

  

Summary:

First, we are very concerned about the re-enumeration of natEvent value= s in section 4.2.  It is not good practice and is disruptive to implem= enters to re-enumerate published values.  Also the values created here are too specific and make this not-easily extended= .    The only exception I might make here is to change the e= xisting "Pool Exhausted" value to be "Translation Failure&qu= ot; or simply add a new enum for this.  I think generic events are better than specific.  More on this below.

&n= bsp;

[Senthi= l] I assume you mean the IPFIX IANA assigned values for natEvents. You are = right, there is an inconsistency between the two. As you pointed out, the c= reate and delete event is consistent with the IPFIX values, we need to add the poolExhausted value in the draft= or create a new value for it.  We will do it as part of the next rev.=  

 

I would like to see this draft reference and be consistent with draft-i= etf-behave-lsn-requirements-x which does describe, in section 4, logging re= quirements for a CGN.  I think this document needs align with the logging requirements here in the overall goals and co= nstraints.  Namely, the primary goal for NAT logging is to enable the = ability to identify a subscriber - often for legal reasons.  The const= raint that we need to be mindful of is logging resource consumption.  Many CGN features are specifically designed to= minimize log size while still maintaining the ability to identify subscrib= ers - Port block allocation for example.

&n= bsp;

[Senthi= l] This document is not just for CGN logging, it is a generic NAT logging d= ocument that can be used also for satisfying CGN logging requirements. As m= entioned in the scope, the optimization of log events (size, the way you pack the records etc) is not within the s= cope of this document. There are many other documents that provide solution= s for that. The main purpose of this document is to provide a framework and= a template to log NAT events – that both the NAT vendors and the collector vendors can use to interoperat= e.

 

CGN logging for the purposes of identifying subscribers and with the go= al of minimizing data consumption, needs to focus on the NAT translations (= bindings) and be as minimalistic as possible.  Flow logging or session logging has a different purpose - statistical, dat= a usage analysis, quality analysis, security, billing…  There ma= y be some overlap of use-cases but this document doesn't really speak to th= em.  It might be interesting to look at typical/traditional NetFlow/IPFIX Flow logging and see how that might be different for a NAT.&= nbsp;  But there are at least 2 different use-cases - if this document= wants to address both, I think it would be useful to distinguish them.&nbs= p; But flow/session logging needs to be discrete because administrators may only choose translation logging for data conser= vation purposes.  It seems to me that your session create/delete event= s fall into this camp, although I’m interested in your intent here.&n= bsp; Minimally I’d be interested in a comparison.

&n= bsp;

[Senthi= l] Just to re-iterate, the focus of the draft is generic NAT logging –= ; not just CGN. The NAT templates defined in the draft is generic enough to= cover both CGN and non-CGN NAT logging. I am not really sure I understand the gist of the above paragraph, but flow = logging is being used for data retention purposes. Again our intention here= is have a generic logging framework. 

 <= o:p>

 

My high level recommendations:

1.  =      Don't renumber I= ANA defined enums.  Reasons cited above. 

&n= bsp;

[Senthi= l] Ok. But a lot of what is defined here is what went on to become IANA val= ues, but your point is well taken, we will get rid of inconsistencies.=

&n= bsp;

2.  =      Keep high level = events generic.  This makes them more extensible.  "Create&q= uot;, "Delete" and "Translation Failure" - with more da= ta as additional (optional) IE's.  For example, keeping the "erro= r" event generic allows collectors to universally identify an error, even as more e= rror types are created. 

[Senthi= l] The problem is if we have a simple create, delete, we wont be able to di= stinguish what kind of an nat this is – nat44, nat64 etc. For us to a= dd additional data, that would cause us to have another byte. In this case, we can have a max of 256 types (with 8 bi= ts) and hence make sense to present the information in one shot. I am open = to suggestions here but would like some WG guidance.

&n= bsp;

3.  =      Be careful about= error logging recommendations.  I would set these as MAY with comment= s about limiting how often these are emitted in a pool exhaustion case so a= s not to DoS the source or target system. 

[Senthi= l] Agreed. 

&n= bsp;

4.  =      Consider DSLite = in your recommendations - what IE's should be used to report a DSLite subsc= riber? 

&n= bsp;

[Senthi= l] We had DS lite in earlier revision of the draft in -03. But the WG wante= d us to keep it specifically to NAT, so the latest versions got rid of them= .

&n= bsp;

5.  =      Make the Port Bl= ock Allocation extensions part of the "Create" and "Delete&q= uot; event templates.

[Senthi= l] Ok.

6.  =      Call out specifi= cally which IE's are new.  Section 7 is not complete or accurate. = ; portRange* ID's have been defined.  You also have IE's identified wh= ich do not exist and are not called out in section 7.

[Senthi= l] Ok.

7.  =      Section 4 - Even= t based Logging:  "Each of these events SHOULD be logged, unless = they are administratively prohibited" - This is a problematic recommen= dation and is contrary to the need to minimize logging (i.e. logging every session )

[Senthi= l] As I clarified above, minimizing logging is not a goal of this draft.

&n= bsp;

8.  =      Bring this into = alignment with draft-behave-lsn-requirements.   E.g. REQ-12. Dest= ination addresses SHOULD NOT be logged.  That said, a mapping event MA= Y have a destination address if administrator requires it.  In which case I would recommend only 1 IE - destinationIPxAddres= s or postNATDestinationIPvxAddress - both seems redundant.

[Senthi= l] I think we can add some text around this, that if the CGN is running, th= en destination address should not be logged.

&n= bsp;

9.  =      Separate out ses= sion logging from translation logging.  Session logging bloats the dat= a set and is unnecessary just for identifying subscribers=

&n= bsp;

&n= bsp;

10.  = ; Describe the dif= ference between session logging and BIB(translation) logging and when to us= e them.  IMHO session logging looks a lot more like flow logging. = ; I'd be interested in a description of the differences and a separate of the two cases.  Perhaps flow logging fo= r NAT's is a separate use-case. 

[Senthi= l] As explained above, for 9 & 10, this is a generic draft.<= /span>

11.  = ; Look at using na= tPoolName optionally in more events - I think it will be useful, minimally = for errors

&n= bsp;

[Senthi= l] Ok.

12.  = ; Can we find an I= E to send a "subscriber identity"?  I'm wondering about #371= , "userName" - for a mobile service provider this might actually = be an IMSI or IMEI numbers.  This would be optional.=

[Senthi= l] I will check, the last time I checked there were a couple of fields that= could be used.  

&n= bsp;

13.  = ; Be mindful of th= e need for data conservation and to minimize logging in your MUST and SHOUL= D requirements.  MUST and SHOULD requirements should be minimalistic t= o achieve the base use-case and nothing more.  E.g. look to the data elements identified in behave-lsn-requir= ements.  But ideally it also gives guidance on some typical use-cases = and how to achieve them.

&n= bsp;

[Senthi= l] Minimizing the logging is not the goal of this draft.<= /p>

 

 

One more nit:  = ; [NAT-EVENT-LOG-IANA] - this link does not exist.  You should update = this to be the IANA IPFIX IE registry.

&n= bsp;

[Senthi= l] Ok, thanks.

 

 

Thanks again for this.&n= bsp; I hope this feedback is helpful.  We look forward to the next dra= ft.

 =

[Senthi= l] Thanks for the helpful comments. Will incorporate the relevant ones.

&n= bsp;

Senthil=

&n= bsp;

Happy New Year,

 =

Julia Renouard

--_000_04B0EA2BFC1C91479AD86F776659AE7530B6C63ESEAEMBX01olympu_-- From ssenthil@cisco.com Fri Jan 4 06:49:38 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147F321F889C for ; Fri, 4 Jan 2013 06:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vfmyx0ePROe9 for ; Fri, 4 Jan 2013 06:49:36 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8419721F8880 for ; Fri, 4 Jan 2013 06:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53045; q=dns/txt; s=iport; t=1357310975; x=1358520575; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=YmdMQ/XW3mPWpTvd7rGbRVPFPOpOO6TKxgqOpfrloZ4=; b=F2Jo6OZAHtdQW55e1a6iemTMh1qyBE2j2K+hWmhGwyIprVjweyiA/gHC 2z3DIifsjRxy5pEg4r4MKGLqUAzgIp9fD17YI+bBH1kCpyIFJoEa30/tZ W/inT+P1Kg7X1Ktj3mXxC4sAECLdRHiwtHkqIj4UMevBvL6bs7pVXHfAm A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAzr5lCtJXHA/2dsb2JhbAA7AQmCSLsEFnOCHgEBAQQaEzokAQgOAwMBAQELCwsBBjkUCQgBAQQBEAIIE4d5tGKMYwF8glRhA5JYk3yCdEGBZQ X-IronPort-AV: E=Sophos;i="4.84,409,1355097600"; d="scan'208,217";a="155876853" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 04 Jan 2013 14:49:34 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r04EnYXH017849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jan 2013 14:49:34 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.156]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 4 Jan 2013 08:49:34 -0600 From: "Senthil Sivakumar (ssenthil)" To: Julia Renouard , "Reinaldo Penno (repenno)" , "behave@ietf.org" Thread-Topic: Comments on draft-sivakumar-behave-nat-logging-05 Thread-Index: Ac3pM+wgT/qoVm2nTy6+PuaNjoLN5QAG6DQAAAApXdAAULiMgA== Date: Fri, 4 Jan 2013 14:49:33 +0000 Message-ID: In-Reply-To: <04B0EA2BFC1C91479AD86F776659AE7530B6C63E@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.117.198.136] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D0232336B9Axmbrcdx15ciscoc_" MIME-Version: 1.0 Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 14:49:38 -0000 --_000_CB1B483277FEC94E9B58357040EE5D0232336B9Axmbrcdx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Julia Renouard > Date: Wednesday, January 2, 2013 9:05 PM To: Senthil Sivakumar >, "Rei= naldo Penno (repenno)" >, "beha= ve@ietf.org" > Subject: RE: Comments on draft-sivakumar-behave-nat-logging-05 Hi Senthil =96 Nice fast turn-around. So part of my confusion here appears= to be derived from your opening sentence in the Abstract and Scope section= s: =93This document provides the information model to be used for logging= the Carrier Grade NAT (CGN) events.=94 So you might want to clarify the = scope as well if this is intended to be broader than CGN. :) My apologies= that I did not review the history of this draft. I started with this for = review =96 a bit in a vacuum I admit. [Senthil] Right, the sentence after the first one says "The logs are requir= ed in many cases to identify an attacker or a host that was used to launch = malicious attacks and/or for various other purposes of accounting.", which = is not specific to CGN. But I agree, it might have been misleading. I will = do some wordsmithing to clarify this better. A follow up thought, if this is intended to be for all NAT types, including= generic NAT and CGN, not paying attention to minimizing logging and the ba= ndwidth and data constraints of the CGN deployments will end up making most= CGN devices to only be partially compliant if the recommendations laid out= here remain a SHOULD or do not take this need into account. We will simpl= y have to use it as high-level guidance and take our own path because minim= izing logging is a requirement for us. Even so, I think it will still be u= seful to identify the common use-cases for logging. This helps better revi= ew if the recommendations you are making achieve those goals or not. [Senthil] The templates and the framework are generic enough that would be = applicable to both. For the log reduction, there are already a couple of dr= afts that talks about ways to do that. On the question of the generic vs specific natEvent enumerations, I actuall= y feel the generic is more extensible, but yes, I agree =96 broader WG opin= ions should be sought and to be honest I have not compared it with other IE= =92s for consistency nor looked at IPFIX collector implementations. My con= cern is as much from a =93best practice=94 of data hiding =96 where events = are generic and type is part of data. This facilitates extensibility and f= uture proofing implementations. The example of the error enumeration is a = good one. As a collector, I can implement to recognize a generic =93Trans= lation error=94 event =96 and I don=92t need to update my software for ever= y new error type that comes along. I know I will catch it. I may not know= what type of error but I will know an error occurred. As for the generic = NAT events vs. specific type-encoded events, yes I understand the goal of h= aving the nat type. You could provide the additional natType IE in the tem= plate but, as you say, that is an additional byte. However IMHO the value = of extensibility outweighs this. In order to add NAT66, for example, you n= ow need to extend this yet again. Not having implemented an IPFIX collec= tor I cannot speak to whether this addition of the NAT type actually resolv= es any ambiguity that the different templates would not. (sourceIPv6Addres= s vs. IPv4). I=92d have to look back in the threads for the feedback on DS-Lite to under= stand the concerns wrt this draft, but as an implementer it is something I = have to solve. I don=92t think it requires any new types. But I think it = would be useful to offer template guidance. For us, we were intending simp= ly to use a sourceIPv6Address IE (consistent with Section 4 in behave-lsn-r= equirements). Optionally we may also include a sourceIPv4Address if the cu= stomer desired. Again, I don=92t think it needs its own IE=92s or types, j= ust template guidance and how this will be interpreted commonly by collecto= rs. Just a thought=85 Thanks again =96 we look forward to the next round. I appreciate your work= here, Julia Thanks Senthil From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] Sent: Wednesday, January 02, 2013 4:14 PM To: Julia Renouard; Reinaldo Penno (repenno); behave@ietf.org Subject: Re: Comments on draft-sivakumar-behave-nat-logging-05 Hi Julia, Thanks for the comments. Please see inline. From: Julia Renouard > Date: Wednesday, January 2, 2013 5:28 PM To: "Reinaldo Penno (repenno)" = >, Senthil Sivakumar >, "beha= ve@ietf.org" > Subject: Comments on draft-sivakumar-behave-nat-logging-05 Hi Reinaldo & Senthil =96 Thank you for your work here. I know this has been through a few iteration= s . I do think this is needed minimally as guidance. This was the only t= hing we found, save for section 4 in behave-lsn-requirements that gave guid= ance on CGN logging. And your justification is spot-on. Now for feedback= =85 Summary: First, we are very concerned about the re-enumeration of natEvent values in= section 4.2. It is not good practice and is disruptive to implementers to= re-enumerate published values. Also the values created here are too speci= fic and make this not-easily extended. The only exception I might make h= ere is to change the existing "Pool Exhausted" value to be "Translation Fai= lure" or simply add a new enum for this. I think generic events are better= than specific. More on this below. [Senthil] I assume you mean the IPFIX IANA assigned values for natEvents. Y= ou are right, there is an inconsistency between the two. As you pointed out= , the create and delete event is consistent with the IPFIX values, we need = to add the poolExhausted value in the draft or create a new value for it. = We will do it as part of the next rev. I would like to see this draft reference and be consistent with draft-ietf-= behave-lsn-requirements-x which does describe, in section 4, logging requir= ements for a CGN. I think this document needs align with the logging requi= rements here in the overall goals and constraints. Namely, the primary goa= l for NAT logging is to enable the ability to identify a subscriber - often= for legal reasons. The constraint that we need to be mindful of is loggin= g resource consumption. Many CGN features are specifically designed to min= imize log size while still maintaining the ability to identify subscribers = - Port block allocation for example. [Senthil] This document is not just for CGN logging, it is a generic NAT lo= gging document that can be used also for satisfying CGN logging requirement= s. As mentioned in the scope, the optimization of log events (size, the way= you pack the records etc) is not within the scope of this document. There = are many other documents that provide solutions for that. The main purpose = of this document is to provide a framework and a template to log NAT events= =96 that both the NAT vendors and the collector vendors can use to interop= erate. CGN logging for the purposes of identifying subscribers and with the goal o= f minimizing data consumption, needs to focus on the NAT translations (bind= ings) and be as minimalistic as possible. Flow logging or session logging = has a different purpose - statistical, data usage analysis, quality analysi= s, security, billing=85 There may be some overlap of use-cases but this do= cument doesn't really speak to them. It might be interesting to look at ty= pical/traditional NetFlow/IPFIX Flow logging and see how that might be diff= erent for a NAT. But there are at least 2 different use-cases - if this d= ocument wants to address both, I think it would be useful to distinguish th= em. But flow/session logging needs to be discrete because administrators m= ay only choose translation logging for data conservation purposes. It seem= s to me that your session create/delete events fall into this camp, althoug= h I=92m interested in your intent here. Minimally I=92d be interested in a= comparison. [Senthil] Just to re-iterate, the focus of the draft is generic NAT logging= =96 not just CGN. The NAT templates defined in the draft is generic enough= to cover both CGN and non-CGN NAT logging. I am not really sure I understa= nd the gist of the above paragraph, but flow logging is being used for data= retention purposes. Again our intention here is have a generic logging fra= mework. My high level recommendations: 1. Don't renumber IANA defined enums. Reasons cited above. [Senthil] Ok. But a lot of what is defined here is what went on to become I= ANA values, but your point is well taken, we will get rid of inconsistencie= s. 2. Keep high level events generic. This makes them more extensible. = "Create", "Delete" and "Translation Failure" - with more data as additiona= l (optional) IE's. For example, keeping the "error" event generic allows c= ollectors to universally identify an error, even as more error types are cr= eated. [Senthil] The problem is if we have a simple create, delete, we wont be abl= e to distinguish what kind of an nat this is =96 nat44, nat64 etc. For us t= o add additional data, that would cause us to have another byte. In this ca= se, we can have a max of 256 types (with 8 bits) and hence make sense to pr= esent the information in one shot. I am open to suggestions here but would = like some WG guidance. 3. Be careful about error logging recommendations. I would set these= as MAY with comments about limiting how often these are emitted in a pool = exhaustion case so as not to DoS the source or target system. [Senthil] Agreed. 4. Consider DSLite in your recommendations - what IE's should be used= to report a DSLite subscriber? [Senthil] We had DS lite in earlier revision of the draft in -03. But the W= G wanted us to keep it specifically to NAT, so the latest versions got rid = of them. 5. Make the Port Block Allocation extensions part of the "Create" and= "Delete" event templates. [Senthil] Ok. 6. Call out specifically which IE's are new. Section 7 is not comple= te or accurate. portRange* ID's have been defined. You also have IE's ide= ntified which do not exist and are not called out in section 7. [Senthil] Ok. 7. Section 4 - Event based Logging: "Each of these events SHOULD be = logged, unless they are administratively prohibited" - This is a problemati= c recommendation and is contrary to the need to minimize logging (i.e. logg= ing every session ) [Senthil] As I clarified above, minimizing logging is not a goal of this dr= aft. 8. Bring this into alignment with draft-behave-lsn-requirements. E.= g. REQ-12. Destination addresses SHOULD NOT be logged. That said, a mappin= g event MAY have a destination address if administrator requires it. In wh= ich case I would recommend only 1 IE - destinationIPxAddress or postNATDest= inationIPvxAddress - both seems redundant. [Senthil] I think we can add some text around this, that if the CGN is runn= ing, then destination address should not be logged. 9. Separate out session logging from translation logging. Session lo= gging bloats the data set and is unnecessary just for identifying subscribe= rs 10. Describe the difference between session logging and BIB(translation) = logging and when to use them. IMHO session logging looks a lot more like f= low logging. I'd be interested in a description of the differences and a s= eparate of the two cases. Perhaps flow logging for NAT's is a separate use= -case. [Senthil] As explained above, for 9 & 10, this is a generic draft. 11. Look at using natPoolName optionally in more events - I think it will= be useful, minimally for errors [Senthil] Ok. 12. Can we find an IE to send a "subscriber identity"? I'm wondering abo= ut #371, "userName" - for a mobile service provider this might actually be = an IMSI or IMEI numbers. This would be optional. [Senthil] I will check, the last time I checked there were a couple of fiel= ds that could be used. 13. Be mindful of the need for data conservation and to minimize logging = in your MUST and SHOULD requirements. MUST and SHOULD requirements should = be minimalistic to achieve the base use-case and nothing more. E.g. look t= o the data elements identified in behave-lsn-requirements. But ideally it = also gives guidance on some typical use-cases and how to achieve them. [Senthil] Minimizing the logging is not the goal of this draft. One more nit: [NAT-EVENT-LOG-IANA] - this link does not exist. You shoul= d update this to be the IANA IPFIX IE registry. [Senthil] Ok, thanks. Thanks again for this. I hope this feedback is helpful. We look forward t= o the next draft. [Senthil] Thanks for the helpful comments. Will incorporate the relevant on= es. Senthil Happy New Year, Julia Renouard --_000_CB1B483277FEC94E9B58357040EE5D0232336B9Axmbrcdx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2E6ADFF7313A0646BD89B8FB492F224E@cisco.com> Content-Transfer-Encoding: quoted-printable


From: Julia Renouard <J.Renouard@F5.com>
Date: Wednesday, January 2, 2013 9:= 05 PM
To: Senthil Sivakumar <ssenthil@cisco.com>, "Reinaldo P= enno (repenno)" <repenno@cisco= .com>, "behave@ietf.org&= quot; <behave@ietf.org>
Subject: RE: Comments on draft-siva= kumar-behave-nat-logging-05

Hi Senthil =96 Nice fa= st turn-around.  So part of my confusion here appears to be derived fr= om your opening sentence in the Abstract and Scope sections:   = =93This document provides the information model to be used for logging the Carrier Grade NAT (CGN) events.=94   So you migh= t want to clarify the scope as well if this is intended to be broader than = CGN.  J  My apologies that I did not review the history= of this draft.  I started with this for review =96 a bit in a vacuum = I admit.

[Senthil] Right, the sentence after = the first one says "The logs are required in many = cases to identify an attacker or a host that was used to launch malicious attacks and/o= r for various other purposes of accounting.", which is not specific to= CGN. But I agree, it might have been misleading. I

 

A follow up thought, i= f this is intended to be for all NAT types, including generic NAT and CGN, = not paying attention to minimizing logging and the bandwidth and data const= raints of the CGN deployments will end up making most CGN devices to only be partially compliant if the recommend= ations laid out here remain a SHOULD or do not take this need into account.=   We will simply have to use it as high-level guidance and take our ow= n path because minimizing logging is a requirement for us.  Even so, I think it will still be useful to id= entify the common use-cases for logging.  This helps better review if = the recommendations you are making achieve those goals or not.

[Senthil] The templates and the framework are generic enough that woul= d be applicable to both. For the log reduction, there are already a couple = of drafts that talks about ways to do that.

 

On the question of the= generic vs specific natEvent enumerations, I actually feel the generic is = more extensible, but yes, I agree =96 broader WG opinions should be sought = and to be honest I have not compared it with other IE=92s for consistency nor looked at IPFIX collector implementa= tions.  My concern is as much from a =93best practice=94 of data hidin= g =96 where events are generic and type is part of data.  This facilit= ates extensibility and future proofing implementations.  The example of the error enumeration is a good one.  As a colle= ctor, I can implement to recognize a generic  =93Translation error=94 = event =96 and I don=92t need to update my software for every new error type= that comes along.  I know I will catch it.  I may not know what type of error but I will know an error occurred.  As for th= e generic NAT events vs. specific type-encoded events, yes I understand the= goal of having the nat type.  You could provide the additional natTyp= e IE in the template but, as you say, that is an additional byte.  However IMHO the value of extensibility outwe= ighs this.  In order to add NAT66, for example, you now need to extend= this yet again.    Not having implemented an IPFIX collecto= r I cannot speak to whether this addition of the NAT type actually resolves any ambiguity that the different templates would not.&nb= sp; (sourceIPv6Address vs. IPv4).    

 

I=92d have to look bac= k in the threads for the feedback on DS-Lite to understand the concerns wrt= this draft, but as an implementer it is something I have to solve.  I= don=92t think it requires any new types.  But I think it would be useful to offer template guidance.  For us, we we= re intending simply to use a sourceIPv6Address IE (consistent with Section = 4 in behave-lsn-requirements).  Optionally we may also include a sourc= eIPv4Address if the customer desired.  Again, I don=92t think it needs its own IE=92s or types, just template guidance a= nd how this will be interpreted commonly by collectors.  Just a though= t=85

 

Thanks again =96 we lo= ok forward to the next round.  I appreciate your work here,=

Julia

 
Thanks
Senthil

 

From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com]
Sent: Wednesday, January 02, 2013 4:14 PM
To: Julia Renouard; Reinaldo Penno (repenno); behave@ietf.org
Subject: Re: Comments on draft-sivakumar-behave-nat-logging-05 =

 

Hi Juli= a,

Thanks = for the comments. Please see inline.

&n= bsp;

From: Julia Renouard <J.Renouard@F5.com>
Date: Wednesday, January 2, 2013 5:28 PM
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>, Senthil Sivakumar <ssenthil@cisco.com>, "behave@ietf.org" <behave@ietf.org>
Subject: Comments on draft-sivakumar-behave-nat-logging-05

&n= bsp;

Hi Reinaldo & Senthil =96

 

Thank you for your work here.  I know this has been through a few = iterations .  I do think this is needed minimally as guidance. &n= bsp; This was the only thing we found, save for section 4 in behave-lsn-requirements that gave guidance on CGN logging.  And yo= ur justification is spot-on.   Now for feedback=85

  

Summary:

First, we are very concerned about the re-enumeration of natEvent value= s in section 4.2.  It is not good practice and is disruptive to implem= enters to re-enumerate published values.  Also the values created here are too specific and make this not-easily extended= .    The only exception I might make here is to change the e= xisting "Pool Exhausted" value to be "Translation Failure&qu= ot; or simply add a new enum for this.  I think generic events are better than specific.  More on this below.

&n= bsp;

[Senthi= l] I assume you mean the IPFIX IANA assigned values for natEvents. You are = right, there is an inconsistency between the two. As you pointed out, the c= reate and delete event is consistent with the IPFIX values, we need to add the poolExhausted value in the draft= or create a new value for it.  We will do it as part of the next rev.=  

 

I would like to see this draft reference and be consistent with draft-i= etf-behave-lsn-requirements-x which does describe, in section 4, logging re= quirements for a CGN.  I think this document needs align with the logging requirements here in the overall goals and co= nstraints.  Namely, the primary goal for NAT logging is to enable the = ability to identify a subscriber - often for legal reasons.  The const= raint that we need to be mindful of is logging resource consumption.  Many CGN features are specifically designed to= minimize log size while still maintaining the ability to identify subscrib= ers - Port block allocation for example.

&n= bsp;

[Senthi= l] This document is not just for CGN logging, it is a generic NAT logging d= ocument that can be used also for satisfying CGN logging requirements. As m= entioned in the scope, the optimization of log events (size, the way you pack the records etc) is not within the s= cope of this document. There are many other documents that provide solution= s for that. The main purpose of this document is to provide a framework and= a template to log NAT events =96 that both the NAT vendors and the collector vendors can use to interoperat= e.

 

CGN logging for the purposes of identifying subscribers and with the go= al of minimizing data consumption, needs to focus on the NAT translations (= bindings) and be as minimalistic as possible.  Flow logging or session logging has a different purpose - statistical, dat= a usage analysis, quality analysis, security, billing=85  There may be= some overlap of use-cases but this document doesn't really speak to them.&= nbsp; It might be interesting to look at typical/traditional NetFlow/IPFIX Flow logging and see how that might be different for a NAT.&= nbsp;  But there are at least 2 different use-cases - if this document= wants to address both, I think it would be useful to distinguish them.&nbs= p; But flow/session logging needs to be discrete because administrators may only choose translation logging for data conser= vation purposes.  It seems to me that your session create/delete event= s fall into this camp, although I=92m interested in your intent here. = Minimally I=92d be interested in a comparison.

&n= bsp;

[Senthi= l] Just to re-iterate, the focus of the draft is generic NAT logging =96 no= t just CGN. The NAT templates defined in the draft is generic enough to cov= er both CGN and non-CGN NAT logging. I am not really sure I understand the gist of the above paragraph, but flow = logging is being used for data retention purposes. Again our intention here= is have a generic logging framework. 

 <= o:p>

 

My high level recommendations:

1.       Don't renumb= er IANA defined enums.  Reasons cited above. 

&n= bsp;

[Senthi= l] Ok. But a lot of what is defined here is what went on to become IANA val= ues, but your point is well taken, we will get rid of inconsistencies.=

&n= bsp;

2.       Keep high le= vel events generic.  This makes them more extensible.  "Crea= te", "Delete" and "Translation Failure" - with mor= e data as additional (optional) IE's.  For example, keeping the "= error" event generic allows collectors to universally identify an error, even as more e= rror types are created. 

[Senthi= l] The problem is if we have a simple create, delete, we wont be able to di= stinguish what kind of an nat this is =96 nat44, nat64 etc. For us to add a= dditional data, that would cause us to have another byte. In this case, we can have a max of 256 types (with 8 bi= ts) and hence make sense to present the information in one shot. I am open = to suggestions here but would like some WG guidance.

&n= bsp;

3.       Be careful a= bout error logging recommendations.  I would set these as MAY with com= ments about limiting how often these are emitted in a pool exhaustion case = so as not to DoS the source or target system. 

[Senthi= l] Agreed. 

&n= bsp;

4.       Consider DSL= ite in your recommendations - what IE's should be used to report a DSLite s= ubscriber? 

&n= bsp;

[Senthi= l] We had DS lite in earlier revision of the draft in -03. But the WG wante= d us to keep it specifically to NAT, so the latest versions got rid of them= .

&n= bsp;

5.       Make the Por= t Block Allocation extensions part of the "Create" and "Dele= te" event templates.

[Senthi= l] Ok.

6.       Call out spe= cifically which IE's are new.  Section 7 is not complete or accurate.&= nbsp; portRange* ID's have been defined.  You also have IE's identifie= d which do not exist and are not called out in section 7.

[Senthi= l] Ok.

7.       Section 4 - = Event based Logging:  "Each of these events SHOULD be logged, unl= ess they are administratively prohibited" - This is a problematic reco= mmendation and is contrary to the need to minimize logging (i.e. logging every session )

[Senthi= l] As I clarified above, minimizing logging is not a goal of this draft.

&n= bsp;

8.       Bring this i= nto alignment with draft-behave-lsn-requirements.   E.g. REQ-12. = Destination addresses SHOULD NOT be logged.  That said, a mapping even= t MAY have a destination address if administrator requires it.  In which case I would recommend only 1 IE - destination= IPxAddress or postNATDestinationIPvxAddress - both seems redundant.

[Senthi= l] I think we can add some text around this, that if the CGN is running, th= en destination address should not be logged.

&n= bsp;

9.       Separate out= session logging from translation logging.  Session logging bloats the= data set and is unnecessary just for identifying subscribers

&n= bsp;

&n= bsp;

10.   Describe the= difference between session logging and BIB(translation) logging and when t= o use them.  IMHO session logging looks a lot more like flow logging.&= nbsp; I'd be interested in a description of the differences and a separate of the two cases.  Perhaps flow loggin= g for NAT's is a separate use-case. 

[Senthi= l] As explained above, for 9 & 10, this is a generic draft.<= /span>

11.   Look at usin= g natPoolName optionally in more events - I think it will be useful, minima= lly for errors

&n= bsp;

[Senthi= l] Ok.

12.   Can we find = an IE to send a "subscriber identity"?  I'm wondering about = #371, "userName" - for a mobile service provider this might actua= lly be an IMSI or IMEI numbers.  This would be optional.

[Senthi= l] I will check, the last time I checked there were a couple of fields that= could be used.  

&n= bsp;

13.   Be mindful o= f the need for data conservation and to minimize logging in your MUST and S= HOULD requirements.  MUST and SHOULD requirements should be minimalist= ic to achieve the base use-case and nothing more.  E.g. look to the data elements identified in behave-lsn-requir= ements.  But ideally it also gives guidance on some typical use-cases = and how to achieve them.

&n= bsp;

[Senthi= l] Minimizing the logging is not the goal of this draft.<= /p>

 

 

One more nit:  = ; [NAT-EVENT-LOG-IANA] - this link does not exist.  You should update = this to be the IANA IPFIX IE registry.

&n= bsp;

[Senthi= l] Ok, thanks.

 

 

Thanks again for this.&n= bsp; I hope this feedback is helpful.  We look forward to the next dra= ft.

 =

[Senthi= l] Thanks for the helpful comments. Will incorporate the relevant ones.

&n= bsp;

Senthil=

&n= bsp;

Happy New Year,

 =

Julia Renouard

 --_000_CB1B483277FEC94E9B58357040EE5D0232336B9Axmbrcdx15ciscoc_-- From Tina.Tsou.Zouting@huawei.com Fri Jan 4 20:41:59 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D303821F84DD for ; Fri, 4 Jan 2013 20:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ0VQKPNiECy for ; Fri, 4 Jan 2013 20:41:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E5BBF21F8488 for ; Fri, 4 Jan 2013 20:41:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANF24458; Sat, 05 Jan 2013 04:41:54 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 5 Jan 2013 04:41:07 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 5 Jan 2013 04:41:53 +0000 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.39]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Fri, 4 Jan 2013 20:41:45 -0800 From: Tina TSOU To: "Senthil Sivakumar (ssenthil)" Thread-Topic: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 Thread-Index: Ac3pM+wgT/qoVm2nTy6+PuaNjoLN5QAG6DQAAAApXdAAULiMgAAa+KQd Date: Sat, 5 Jan 2013 04:41:45 +0000 Message-ID: References: <04B0EA2BFC1C91479AD86F776659AE7530B6C63E@SEAEMBX01.olympus.F5Net.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CE2BD18F590D4F04B416BCC6F6B5D4C8huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "behave@ietf.org" , "Reinaldo Penno \(repenno\)" , Julia Renouard , "Draft-Tsou-Behave-Natx4-Log-Reduction@Tools. Ietf. Org" Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 04:42:00 -0000 --_000_CE2BD18F590D4F04B416BCC6F6B5D4C8huaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Senthil, Reinaldo et al, Draft-sivakumar does describe dynamically assign port range and take logs b= ased on port range, which overlaps much with draft-tsou-behave-natx4-log-re= duction. http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-05#section-4.= 4.9 describes allocating and retrieving port range, but it is not clear whe= ther one user can have multiple port range, or only one. Though the focus of this draft is not how to allocate port range, only ment= ions what content in the recorded information. This draft currently only supports continuous port range, not non-continuou= s one. So I propose these two drafts converge. Thank you, Tina On Jan 4, 2013, at 6:49 AM, "Senthil Sivakumar (ssenthil)" > wrote: From: Julia Renouard > Date: Wednesday, January 2, 2013 9:05 PM To: Senthil Sivakumar >, "Rei= naldo Penno (repenno)" >, "beha= ve@ietf.org" > Subject: RE: Comments on draft-sivakumar-behave-nat-logging-05 Hi Senthil =96 Nice fast turn-around. So part of my confusion here appears= to be derived from your opening sentence in the Abstract and Scope section= s: =93This document provides the information model to be used for logging= the Carrier Grade NAT (CGN) events.=94 So you might want to clarify the = scope as well if this is intended to be broader than CGN. :) My apologies= that I did not review the history of this draft. I started with this for = review =96 a bit in a vacuum I admit. [Senthil] Right, the sentence after the first one says "The logs are requir= ed in many cases to identify an attacker or a host that was used to launch = malicious attacks and/or for various other purposes of accounting.", which = is not specific to CGN. But I agree, it might have been misleading. I will = do some wordsmithing to clarify this better. A follow up thought, if this is intended to be for all NAT types, including= generic NAT and CGN, not paying attention to minimizing logging and the ba= ndwidth and data constraints of the CGN deployments will end up making most= CGN devices to only be partially compliant if the recommendations laid out= here remain a SHOULD or do not take this need into account. We will simpl= y have to use it as high-level guidance and take our own path because minim= izing logging is a requirement for us. Even so, I think it will still be u= seful to identify the common use-cases for logging. This helps better revi= ew if the recommendations you are making achieve those goals or not. [Senthil] The templates and the framework are generic enough that would be = applicable to both. For the log reduction, there are already a couple of dr= afts that talks about ways to do that. On the question of the generic vs specific natEvent enumerations, I actuall= y feel the generic is more extensible, but yes, I agree =96 broader WG opin= ions should be sought and to be honest I have not compared it with other IE= =92s for consistency nor looked at IPFIX collector implementations. My con= cern is as much from a =93best practice=94 of data hiding =96 where events = are generic and type is part of data. This facilitates extensibility and f= uture proofing implementations. The example of the error enumeration is a = good one. As a collector, I can implement to recognize a generic =93Trans= lation error=94 event =96 and I don=92t need to update my software for ever= y new error type that comes along. I know I will catch it. I may not know= what type of error but I will know an error occurred. As for the generic = NAT events vs. specific type-encoded events, yes I understand the goal of h= aving the nat type. You could provide the additional natType IE in the tem= plate but, as you say, that is an additional byte. However IMHO the value = of extensibility outweighs this. In order to add NAT66, for example, you n= ow need to extend this yet again. Not having implemented an IPFIX collec= tor I cannot speak to whether this addition of the NAT type actually resolv= es any ambiguity that the different templates would not. (sourceIPv6Addres= s vs. IPv4). I=92d have to look back in the threads for the feedback on DS-Lite to under= stand the concerns wrt this draft, but as an implementer it is something I = have to solve. I don=92t think it requires any new types. But I think it = would be useful to offer template guidance. For us, we were intending simp= ly to use a sourceIPv6Address IE (consistent with Section 4 in behave-lsn-r= equirements). Optionally we may also include a sourceIPv4Address if the cu= stomer desired. Again, I don=92t think it needs its own IE=92s or types, j= ust template guidance and how this will be interpreted commonly by collecto= rs. Just a thought=85 Thanks again =96 we look forward to the next round. I appreciate your work= here, Julia Thanks Senthil From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] Sent: Wednesday, January 02, 2013 4:14 PM To: Julia Renouard; Reinaldo Penno (repenno); behave@ietf.org Subject: Re: Comments on draft-sivakumar-behave-nat-logging-05 Hi Julia, Thanks for the comments. Please see inline. From: Julia Renouard > Date: Wednesday, January 2, 2013 5:28 PM To: "Reinaldo Penno (repenno)" = >, Senthil Sivakumar >, "beha= ve@ietf.org" > Subject: Comments on draft-sivakumar-behave-nat-logging-05 Hi Reinaldo & Senthil =96 Thank you for your work here. I know this has been through a few iteration= s . I do think this is needed minimally as guidance. This was the only t= hing we found, save for section 4 in behave-lsn-requirements that gave guid= ance on CGN logging. And your justification is spot-on. Now for feedback= =85 Summary: First, we are very concerned about the re-enumeration of natEvent values in= section 4.2. It is not good practice and is disruptive to implementers to= re-enumerate published values. Also the values created here are too speci= fic and make this not-easily extended. The only exception I might make h= ere is to change the existing "Pool Exhausted" value to be "Translation Fai= lure" or simply add a new enum for this. I think generic events are better= than specific. More on this below. [Senthil] I assume you mean the IPFIX IANA assigned values for natEvents. Y= ou are right, there is an inconsistency between the two. As you pointed out= , the create and delete event is consistent with the IPFIX values, we need = to add the poolExhausted value in the draft or create a new value for it. = We will do it as part of the next rev. I would like to see this draft reference and be consistent with draft-ietf-= behave-lsn-requirements-x which does describe, in section 4, logging requir= ements for a CGN. I think this document needs align with the logging requi= rements here in the overall goals and constraints. Namely, the primary goa= l for NAT logging is to enable the ability to identify a subscriber - often= for legal reasons. The constraint that we need to be mindful of is loggin= g resource consumption. Many CGN features are specifically designed to min= imize log size while still maintaining the ability to identify subscribers = - Port block allocation for example. [Senthil] This document is not just for CGN logging, it is a generic NAT lo= gging document that can be used also for satisfying CGN logging requirement= s. As mentioned in the scope, the optimization of log events (size, the way= you pack the records etc) is not within the scope of this document. There = are many other documents that provide solutions for that. The main purpose = of this document is to provide a framework and a template to log NAT events= =96 that both the NAT vendors and the collector vendors can use to interop= erate. CGN logging for the purposes of identifying subscribers and with the goal o= f minimizing data consumption, needs to focus on the NAT translations (bind= ings) and be as minimalistic as possible. Flow logging or session logging = has a different purpose - statistical, data usage analysis, quality analysi= s, security, billing=85 There may be some overlap of use-cases but this do= cument doesn't really speak to them. It might be interesting to look at ty= pical/traditional NetFlow/IPFIX Flow logging and see how that might be diff= erent for a NAT. But there are at least 2 different use-cases - if this d= ocument wants to address both, I think it would be useful to distinguish th= em. But flow/session logging needs to be discrete because administrators m= ay only choose translation logging for data conservation purposes. It seem= s to me that your session create/delete events fall into this camp, althoug= h I=92m interested in your intent here. Minimally I=92d be interested in a= comparison. [Senthil] Just to re-iterate, the focus of the draft is generic NAT logging= =96 not just CGN. The NAT templates defined in the draft is generic enough= to cover both CGN and non-CGN NAT logging. I am not really sure I understa= nd the gist of the above paragraph, but flow logging is being used for data= retention purposes. Again our intention here is have a generic logging fra= mework. My high level recommendations: 1. Don't renumber IANA defined enums. Reasons cited above. [Senthil] Ok. But a lot of what is defined here is what went on to become I= ANA values, but your point is well taken, we will get rid of inconsistencie= s. 2. Keep high level events generic. This makes them more extensible. = "Create", "Delete" and "Translation Failure" - with more data as additiona= l (optional) IE's. For example, keeping the "error" event generic allows c= ollectors to universally identify an error, even as more error types are cr= eated. [Senthil] The problem is if we have a simple create, delete, we wont be abl= e to distinguish what kind of an nat this is =96 nat44, nat64 etc. For us t= o add additional data, that would cause us to have another byte. In this ca= se, we can have a max of 256 types (with 8 bits) and hence make sense to pr= esent the information in one shot. I am open to suggestions here but would = like some WG guidance. 3. Be careful about error logging recommendations. I would set these= as MAY with comments about limiting how often these are emitted in a pool = exhaustion case so as not to DoS the source or target system. [Senthil] Agreed. 4. Consider DSLite in your recommendations - what IE's should be used= to report a DSLite subscriber? [Senthil] We had DS lite in earlier revision of the draft in -03. But the W= G wanted us to keep it specifically to NAT, so the latest versions got rid = of them. 5. Make the Port Block Allocation extensions part of the "Create" and= "Delete" event templates. [Senthil] Ok. 6. Call out specifically which IE's are new. Section 7 is not comple= te or accurate. portRange* ID's have been defined. You also have IE's ide= ntified which do not exist and are not called out in section 7. [Senthil] Ok. 7. Section 4 - Event based Logging: "Each of these events SHOULD be = logged, unless they are administratively prohibited" - This is a problemati= c recommendation and is contrary to the need to minimize logging (i.e. logg= ing every session ) [Senthil] As I clarified above, minimizing logging is not a goal of this dr= aft. 8. Bring this into alignment with draft-behave-lsn-requirements. E.= g. REQ-12. Destination addresses SHOULD NOT be logged. That said, a mappin= g event MAY have a destination address if administrator requires it. In wh= ich case I would recommend only 1 IE - destinationIPxAddress or postNATDest= inationIPvxAddress - both seems redundant. [Senthil] I think we can add some text around this, that if the CGN is runn= ing, then destination address should not be logged. 9. Separate out session logging from translation logging. Session lo= gging bloats the data set and is unnecessary just for identifying subscribe= rs 10. Describe the difference between session logging and BIB(translation) = logging and when to use them. IMHO session logging looks a lot more like f= low logging. I'd be interested in a description of the differences and a s= eparate of the two cases. Perhaps flow logging for NAT's is a separate use= -case. [Senthil] As explained above, for 9 & 10, this is a generic draft. 11. Look at using natPoolName optionally in more events - I think it will= be useful, minimally for errors [Senthil] Ok. 12. Can we find an IE to send a "subscriber identity"? I'm wondering abo= ut #371, "userName" - for a mobile service provider this might actually be = an IMSI or IMEI numbers. This would be optional. [Senthil] I will check, the last time I checked there were a couple of fiel= ds that could be used. 13. Be mindful of the need for data conservation and to minimize logging = in your MUST and SHOULD requirements. MUST and SHOULD requirements should = be minimalistic to achieve the base use-case and nothing more. E.g. look t= o the data elements identified in behave-lsn-requirements. But ideally it = also gives guidance on some typical use-cases and how to achieve them. [Senthil] Minimizing the logging is not the goal of this draft. One more nit: [NAT-EVENT-LOG-IANA] - this link does not exist. You shoul= d update this to be the IANA IPFIX IE registry. [Senthil] Ok, thanks. Thanks again for this. I hope this feedback is helpful. We look forward t= o the next draft. [Senthil] Thanks for the helpful comments. Will incorporate the relevant on= es. Senthil Happy New Year, Julia Renouard --_000_CE2BD18F590D4F04B416BCC6F6B5D4C8huaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dear Senthil, Reinaldo et al,
Draft-sivakumar does describe dynamically assign port range and take l= ogs based on port range, which overlaps much with draft-tsou-behave-natx4-l= og-reduction.

 

http://tools.ietf.org/html/draft-siv= akumar-behave-nat-logging-05#section-4.4.9 describes allocating and retrieving port range, but it is not clear whether one user= can have multiple port range, or only one.

 

Though the focus of this draft is not = how to allocate port range, only mentions what content in the recorded info= rmation. 

This draft currently only supports con= tinuous port range, not non-continuous one.


So I propose these two drafts converge= .


Thank you,
Tina

On Jan 4, 2013, at 6:49 AM, "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com> wrote:



From: Julia Renouard <J.Renouard@F5.com>
Date: Wednesday, January 2, 2013 9:= 05 PM
To: Senthil Sivakumar <ssenthil@cisco.com>, "Reinaldo P= enno (repenno)" <repenno@cisco= .com>, "behave@ietf.org&= quot; <behave@ietf.org>
Subject: RE: Comments on draft-siva= kumar-behave-nat-logging-05

Hi Senthil =96 Nice fa= st turn-around.  So part of my confusion here appears to be derived fr= om your opening sentence in the Abstract and Scope sections:   = =93This document provides the information model to be used for logging the Carrier Grade NAT (CGN) events.=94   So you migh= t want to clarify the scope as well if this is intended to be broader than = CGN.  J  My apologies that I did not review the history= of this draft.  I started with this for review =96 a bit in a vacuum = I admit.

[Senthil] Right, the sentence after = the first one says "The logs are required in many = cases to identify an attacker or a host that was used to launch malicious attacks and/o= r for various other purposes of accounting.", which is not specific to= CGN. But I agree, it might have been misleading. I

 

A follow up thought, i= f this is intended to be for all NAT types, including generic NAT and CGN, = not paying attention to minimizing logging and the bandwidth and data const= raints of the CGN deployments will end up making most CGN devices to only be partially compliant if the recommend= ations laid out here remain a SHOULD or do not take this need into account.=   We will simply have to use it as high-level guidance and take our ow= n path because minimizing logging is a requirement for us.  Even so, I think it will still be useful to id= entify the common use-cases for logging.  This helps better review if = the recommendations you are making achieve those goals or not.

[Senthil] The templates and the framework are generic enough that woul= d be applicable to both. For the log reduction, there are already a couple = of drafts that talks about ways to do that.

 

On the question of the= generic vs specific natEvent enumerations, I actually feel the generic is = more extensible, but yes, I agree =96 broader WG opinions should be sought = and to be honest I have not compared it with other IE=92s for consistency nor looked at IPFIX collector implementa= tions.  My concern is as much from a =93best practice=94 of data hidin= g =96 where events are generic and type is part of data.  This facilit= ates extensibility and future proofing implementations.  The example of the error enumeration is a good one.  As a colle= ctor, I can implement to recognize a generic  =93Translation error=94 = event =96 and I don=92t need to update my software for every new error type= that comes along.  I know I will catch it.  I may not know what type of error but I will know an error occurred.  As for th= e generic NAT events vs. specific type-encoded events, yes I understand the= goal of having the nat type.  You could provide the additional natTyp= e IE in the template but, as you say, that is an additional byte.  However IMHO the value of extensibility outwe= ighs this.  In order to add NAT66, for example, you now need to extend= this yet again.    Not having implemented an IPFIX collecto= r I cannot speak to whether this addition of the NAT type actually resolves any ambiguity that the different templates would not.&nb= sp; (sourceIPv6Address vs. IPv4).    

 

I=92d have to look bac= k in the threads for the feedback on DS-Lite to understand the concerns wrt= this draft, but as an implementer it is something I have to solve.  I= don=92t think it requires any new types.  But I think it would be useful to offer template guidance.  For us, we we= re intending simply to use a sourceIPv6Address IE (consistent with Section = 4 in behave-lsn-requirements).  Optionally we may also include a sourc= eIPv4Address if the customer desired.  Again, I don=92t think it needs its own IE=92s or types, just template guidance a= nd how this will be interpreted commonly by collectors.  Just a though= t=85

 

Thanks again =96 we lo= ok forward to the next round.  I appreciate your work here,=

Julia

 
Thanks
Senthil

 

From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com]
Sent: Wednesday, January 02, 2013 4:14 PM
To: Julia Renouard; Reinaldo Penno (repenno); behave@ietf.org
Subject: Re: Comments on draft-sivakumar-behave-nat-logging-05 =

 

Hi Juli= a,

Thanks = for the comments. Please see inline.

&n= bsp;

From: Julia Renouard <J.Renouard@F5.com>
Date: Wednesday, January 2, 2013 5:28 PM
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>, Senthil Sivakumar <ssenthil@cisco.com>, "behave@ietf.org" <behave@ietf.org>
Subject: Comments on draft-sivakumar-behave-nat-logging-05

&n= bsp;

Hi Reinaldo & Senthil =96

 

Thank you for your work here.  I know this has been through a few = iterations .  I do think this is needed minimally as guidance. &n= bsp; This was the only thing we found, save for section 4 in behave-lsn-requirements that gave guidance on CGN logging.  And yo= ur justification is spot-on.   Now for feedback=85

  

Summary:

First, we are very concerned about the re-enumeration of natEvent value= s in section 4.2.  It is not good practice and is disruptive to implem= enters to re-enumerate published values.  Also the values created here are too specific and make this not-easily extended= .    The only exception I might make here is to change the e= xisting "Pool Exhausted" value to be "Translation Failure&qu= ot; or simply add a new enum for this.  I think generic events are better than specific.  More on this below.

&n= bsp;

[Senthi= l] I assume you mean the IPFIX IANA assigned values for natEvents. You are = right, there is an inconsistency between the two. As you pointed out, the c= reate and delete event is consistent with the IPFIX values, we need to add the poolExhausted value in the draft= or create a new value for it.  We will do it as part of the next rev.=  

 

I would like to see this draft reference and be consistent with draft-i= etf-behave-lsn-requirements-x which does describe, in section 4, logging re= quirements for a CGN.  I think this document needs align with the logging requirements here in the overall goals and co= nstraints.  Namely, the primary goal for NAT logging is to enable the = ability to identify a subscriber - often for legal reasons.  The const= raint that we need to be mindful of is logging resource consumption.  Many CGN features are specifically designed to= minimize log size while still maintaining the ability to identify subscrib= ers - Port block allocation for example.

&n= bsp;

[Senthi= l] This document is not just for CGN logging, it is a generic NAT logging d= ocument that can be used also for satisfying CGN logging requirements. As m= entioned in the scope, the optimization of log events (size, the way you pack the records etc) is not within the s= cope of this document. There are many other documents that provide solution= s for that. The main purpose of this document is to provide a framework and= a template to log NAT events =96 that both the NAT vendors and the collector vendors can use to interoperat= e.

 

CGN logging for the purposes of identifying subscribers and with the go= al of minimizing data consumption, needs to focus on the NAT translations (= bindings) and be as minimalistic as possible.  Flow logging or session logging has a different purpose - statistical, dat= a usage analysis, quality analysis, security, billing=85  There may be= some overlap of use-cases but this document doesn't really speak to them.&= nbsp; It might be interesting to look at typical/traditional NetFlow/IPFIX Flow logging and see how that might be different for a NAT.&= nbsp;  But there are at least 2 different use-cases - if this document= wants to address both, I think it would be useful to distinguish them.&nbs= p; But flow/session logging needs to be discrete because administrators may only choose translation logging for data conser= vation purposes.  It seems to me that your session create/delete event= s fall into this camp, although I=92m interested in your intent here. = Minimally I=92d be interested in a comparison.

&n= bsp;

[Senthi= l] Just to re-iterate, the focus of the draft is generic NAT logging =96 no= t just CGN. The NAT templates defined in the draft is generic enough to cov= er both CGN and non-CGN NAT logging. I am not really sure I understand the gist of the above paragraph, but flow = logging is being used for data retention purposes. Again our intention here= is have a generic logging framework. 

 <= o:p>

 

My high level recommendations:

1.       Don't renumb= er IANA defined enums.  Reasons cited above. 

&n= bsp;

[Senthi= l] Ok. But a lot of what is defined here is what went on to become IANA val= ues, but your point is well taken, we will get rid of inconsistencies.=

&n= bsp;

2.       Keep high le= vel events generic.  This makes them more extensible.  "Crea= te", "Delete" and "Translation Failure" - with mor= e data as additional (optional) IE's.  For example, keeping the "= error" event generic allows collectors to universally identify an error, even as more e= rror types are created. 

[Senthi= l] The problem is if we have a simple create, delete, we wont be able to di= stinguish what kind of an nat this is =96 nat44, nat64 etc. For us to add a= dditional data, that would cause us to have another byte. In this case, we can have a max of 256 types (with 8 bi= ts) and hence make sense to present the information in one shot. I am open = to suggestions here but would like some WG guidance.

&n= bsp;

3.       Be careful a= bout error logging recommendations.  I would set these as MAY with com= ments about limiting how often these are emitted in a pool exhaustion case = so as not to DoS the source or target system. 

[Senthi= l] Agreed. 

&n= bsp;

4.       Consider DSL= ite in your recommendations - what IE's should be used to report a DSLite s= ubscriber? 

&n= bsp;

[Senthi= l] We had DS lite in earlier revision of the draft in -03. But the WG wante= d us to keep it specifically to NAT, so the latest versions got rid of them= .

&n= bsp;

5.       Make the Por= t Block Allocation extensions part of the "Create" and "Dele= te" event templates.

[Senthi= l] Ok.

6.       Call out spe= cifically which IE's are new.  Section 7 is not complete or accurate.&= nbsp; portRange* ID's have been defined.  You also have IE's identifie= d which do not exist and are not called out in section 7.

[Senthi= l] Ok.

7.       Section 4 - = Event based Logging:  "Each of these events SHOULD be logged, unl= ess they are administratively prohibited" - This is a problematic reco= mmendation and is contrary to the need to minimize logging (i.e. logging every session )

[Senthi= l] As I clarified above, minimizing logging is not a goal of this draft.

&n= bsp;

8.       Bring this i= nto alignment with draft-behave-lsn-requirements.   E.g. REQ-12. = Destination addresses SHOULD NOT be logged.  That said, a mapping even= t MAY have a destination address if administrator requires it.  In which case I would recommend only 1 IE - destination= IPxAddress or postNATDestinationIPvxAddress - both seems redundant.

[Senthi= l] I think we can add some text around this, that if the CGN is running, th= en destination address should not be logged.

&n= bsp;

9.       Separate out= session logging from translation logging.  Session logging bloats the= data set and is unnecessary just for identifying subscribers

&n= bsp;

&n= bsp;

10.   Describe the= difference between session logging and BIB(translation) logging and when t= o use them.  IMHO session logging looks a lot more like flow logging.&= nbsp; I'd be interested in a description of the differences and a separate of the two cases.  Perhaps flow loggin= g for NAT's is a separate use-case. 

[Senthi= l] As explained above, for 9 & 10, this is a generic draft.<= /span>

11.   Look at usin= g natPoolName optionally in more events - I think it will be useful, minima= lly for errors

&n= bsp;

[Senthi= l] Ok.

12.   Can we find = an IE to send a "subscriber identity"?  I'm wondering about = #371, "userName" - for a mobile service provider this might actua= lly be an IMSI or IMEI numbers.  This would be optional.

[Senthi= l] I will check, the last time I checked there were a couple of fields that= could be used.  

&n= bsp;

13.   Be mindful o= f the need for data conservation and to minimize logging in your MUST and S= HOULD requirements.  MUST and SHOULD requirements should be minimalist= ic to achieve the base use-case and nothing more.  E.g. look to the data elements identified in behave-lsn-requir= ements.  But ideally it also gives guidance on some typical use-cases = and how to achieve them.

&n= bsp;

[Senthi= l] Minimizing the logging is not the goal of this draft.<= /p>

 

 

One more nit:  = ; [NAT-EVENT-LOG-IANA] - this link does not exist.  You should update = this to be the IANA IPFIX IE registry.

&n= bsp;

[Senthi= l] Ok, thanks.

 

 

Thanks again for this.&n= bsp; I hope this feedback is helpful.  We look forward to the next dra= ft.

 =

[Senthi= l] Thanks for the helpful comments. Will incorporate the relevant ones.

&n= bsp;

Senthil=

&n= bsp;

Happy New Year,

 =

Julia Renouard

--_000_CE2BD18F590D4F04B416BCC6F6B5D4C8huaweicom_-- From acee.lindem@ericsson.com Sat Jan 5 03:43:03 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2C921F8689 for ; Sat, 5 Jan 2013 03:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvy5dauWFXJQ for ; Sat, 5 Jan 2013 03:43:02 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id E26F921F867E for ; Sat, 5 Jan 2013 03:43:01 -0800 (PST) Received: from EUSAAHC002.ericsson.se ([147.117.188.78]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id r05BgsNe008499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 5 Jan 2013 05:42:55 -0600 Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.004; Sat, 5 Jan 2013 06:42:54 -0500 From: Acee Lindem To: "behave@ietf.org" Thread-Topic: Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 Thread-Index: AQHN6znMi2Ids5peGES2M7/OeqN/yQ== Date: Sat, 5 Jan 2013 11:42:53 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE4708637E@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <8CBF70F2E2CF014FB31AB2144E1CDB63@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Dean Cheng , Alvaro Retana , Mohamed Boucadair Subject: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 11:43:03 -0000 We have WG last called the subject draft in the OSPF WG. It describes usage= of a separate OSPFv3 instance in support of RFC 6052 address translation.= =20 Please comment by Saturday, January 19th, 2013. Here is a URL to the subjec= t document:=20 http://www.ietf.org/id/draft-ietf-ospf-ipv4-embedded-ipv6-routing-05.txt Thanks, Acee=20 From iljitsch@muada.com Mon Jan 14 05:14:52 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA2921F8726 for ; Mon, 14 Jan 2013 05:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiM5JyiXdgG5 for ; Mon, 14 Jan 2013 05:14:51 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 7C29C21F8717 for ; Mon, 14 Jan 2013 05:14:43 -0800 (PST) Received: from [IPv6:2001:470:1f0b:1289:18cf:dd8f:1d43:ce0d] ([IPv6:2001:470:1f0b:1289:18cf:dd8f:1d43:ce0d]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r0EDAaPm064711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 14 Jan 2013 14:10:37 +0100 (CET) (envelope-from iljitsch@muada.com) From: Iljitsch van Beijnum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> Date: Mon, 14 Jan 2013 14:14:46 +0100 To: behave@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 13:14:52 -0000 Hi all, One of the issues with carrier grade NAT is that it breaks IPv6-in-IPv4 = tunneling mechanisms that use protocol 41 encapsulation, because here = the IPv6 header follows the IPv4 header without a UDP header or anything = else containing something resembling port numbers in between. However, it doesn't seem too difficult to make protocol 41 NATing work: = simply use the embedded IPv6 destination address for demultiplexing. = With this in place, existing IPv6-enabled home gateways could talk to = existing tunnel brokers (tunnelbroker.net, sixxs.net) even though = there's a carrier grade NAT in the middle. Thoughts? Iljitsch= From gib-ietf-behave@m.gmane.org Mon Jan 14 08:59:55 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB52821F8824 for ; Mon, 14 Jan 2013 08:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LR0ziqeQxbZ for ; Mon, 14 Jan 2013 08:59:55 -0800 (PST) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by ietfa.amsl.com (Postfix) with ESMTP id 3A66921F8782 for ; Mon, 14 Jan 2013 08:59:55 -0800 (PST) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TunOI-0004Es-5P for behave@ietf.org; Mon, 14 Jan 2013 18:00:06 +0100 Received: from 32.97.110.63 ([32.97.110.63]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Jan 2013 18:00:06 +0100 Received: from wmf by 32.97.110.63 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Jan 2013 18:00:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: behave@ietf.org From: Wes Felter Date: Mon, 14 Jan 2013 10:54:22 -0600 Lines: 11 Message-ID: References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 32.97.110.63 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 In-Reply-To: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 16:59:55 -0000 On 1/14/13 7:14 AM, Iljitsch van Beijnum wrote: > One of the issues with carrier grade NAT is that it breaks IPv6-in-IPv4 tunneling mechanisms that use protocol 41 encapsulation, because here the IPv6 header follows the IPv4 header without a UDP header or anything else containing something resembling port numbers in between. If CGN is in place, then native IPv6 should also be there and there's little need for those tunnels. IMO tunnel brokers are a placebo that's slowing down adoption of real IPv6. -- Wes Felter IBM Research - Austin From brian.e.carpenter@gmail.com Mon Jan 14 09:12:53 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC9921F84DC for ; Mon, 14 Jan 2013 09:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.435 X-Spam-Level: X-Spam-Status: No, score=-101.435 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajMn8Ucpx6mx for ; Mon, 14 Jan 2013 09:12:53 -0800 (PST) Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id C504D21F84B2 for ; Mon, 14 Jan 2013 09:12:52 -0800 (PST) Received: by mail-ea0-f174.google.com with SMTP id 1so360311eaa.33 for ; Mon, 14 Jan 2013 09:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0FBUbeFOYZgnAyz+PLHLeIstamM12zha3mi9SlpFuiE=; b=xoh+4ZLs3QPrNmcbbWxbtaPuk2f3vNLM4G8F51jZFrxfxrlJJeghQHX/srMuy/g1bI uUKRQu5VYCyhIc5l3TxsZyQSxqGB6V6IdKGrmznNazguBc4dCepLctYeKCF+WMrAO01J Af1eXn71s6ehuFaDaQcySIKX+sGUDdq12OO0g2Xuw56XO9EvxsozdcJidG+XirOfpXuF IIKFEq8Ep3eEsEE5+GUSxT89tO5itT6vwchXsZLlnSTuLhBRCMl0wGJan279uD2RfnII DR0AN+4efM6/ymahr995raF2mWr3q1CglHUPwA882Fr1YADZbwRXULkJnw+h7Q/+RaCB d4EQ== X-Received: by 10.14.177.1 with SMTP id c1mr231380256eem.8.1358183571901; Mon, 14 Jan 2013 09:12:51 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-175.as13285.net. [2.102.216.175]) by mx.google.com with ESMTPS id 46sm22211028eeg.4.2013.01.14.09.12.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jan 2013 09:12:51 -0800 (PST) Message-ID: <50F43C96.4050709@gmail.com> Date: Mon, 14 Jan 2013 17:12:54 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Wes Felter References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:12:53 -0000 On 14/01/2013 16:54, Wes Felter wrote: > On 1/14/13 7:14 AM, Iljitsch van Beijnum wrote: > >> One of the issues with carrier grade NAT is that it breaks >> IPv6-in-IPv4 tunneling mechanisms that use protocol 41 encapsulation, >> because here the IPv6 header follows the IPv4 header without a UDP >> header or anything else containing something resembling port numbers >> in between. > > If CGN is in place, then native IPv6 should also be there We can agree that it *should* be there, but only if the ISP has decided to put it there, and many haven't, unfortunately. > and there's > little need for those tunnels. IMO tunnel brokers are a placebo that's > slowing down adoption of real IPv6. One thing they are not is a placebo (something that works by a psychological effect). For users stuck behind a reluctant ISP, they are by contrast the only solution, which is why I use SixXs. otoh I don't think that adding this feature to a CGN is the best use of an ISP's time. See RFC 6264. Brian From simon.perreault@viagenie.ca Mon Jan 14 09:21:40 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6DF21F8803 for ; Mon, 14 Jan 2013 09:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8wYbp+Iivxy for ; Mon, 14 Jan 2013 09:21:39 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 97C3121F87FF for ; Mon, 14 Jan 2013 09:21:39 -0800 (PST) Received: from [127.0.0.1] (unknown [193.49.159.161]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1088B40397 for ; Mon, 14 Jan 2013 12:21:38 -0500 (EST) Message-ID: <50F43ED1.4020704@viagenie.ca> Date: Mon, 14 Jan 2013 18:22:25 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: behave@ietf.org References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> In-Reply-To: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:21:40 -0000 Le 2013-01-14 14:14, Iljitsch van Beijnum a écrit : > However, it doesn't seem too difficult to make protocol 41 NATing > work: simply use the embedded IPv6 destination address for > demultiplexing. With this in place, existing IPv6-enabled home > gateways could talk to existing tunnel brokers (tunnelbroker.net, > sixxs.net) even though there's a carrier grade NAT in the middle. BCP: don't use proto 41 behind a NAT. Use an IPv6 tunnelling protocol that supports NAT. E.g.: TSP [RFC5572], which is used at freenet6.net. Simon From cb.list6@gmail.com Mon Jan 14 09:23:11 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C8A21F87D5 for ; Mon, 14 Jan 2013 09:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkE7AubeORWS for ; Mon, 14 Jan 2013 09:23:09 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by ietfa.amsl.com (Postfix) with ESMTP id EBC5821F874C for ; Mon, 14 Jan 2013 09:23:08 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id fq13so4155539lab.19 for ; Mon, 14 Jan 2013 09:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=miW+y/H/PMtrGOeQijdQThPHILGjhVEm0dufQVi6mQg=; b=XZ/YUTYzMIT8eLcyWdo7QRVtuz37+Jh7UVH305eoffM45J2IwCE8in56LHVLkUbOkD n/0z1qn+hNHD4VVnh1bMLt1utMhhIKj/4CcBeXEjvNcsr5FQpEqSwKNq316cT/V9BZXb RPlL9OHy30jaZY7SP4ZHxEclAdnblz0y02PlxyOME5e/P34GY0jdrBWMHQ9eu/Tk+3cL fLSvTMVsXSfjQnQQuGLK3Wc1ZlXlXNVkfW1FHQIQob0YAj6baWgOTKdgJTtHocKNo3xY Q5YElT+qIMQvUCPJQ40CpyKSLhWsL0RYtpk6HPxOQXbJrg5g7vYiXgyG6+KK4N5NxPf/ 08ew== MIME-Version: 1.0 Received: by 10.152.124.15 with SMTP id me15mr83502998lab.5.1358184187890; Mon, 14 Jan 2013 09:23:07 -0800 (PST) Received: by 10.112.44.36 with HTTP; Mon, 14 Jan 2013 09:23:07 -0800 (PST) In-Reply-To: <50F43ED1.4020704@viagenie.ca> References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> <50F43ED1.4020704@viagenie.ca> Date: Mon, 14 Jan 2013 09:23:07 -0800 Message-ID: From: Cameron Byrne To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: behave@ietf.org Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 17:23:11 -0000 On Mon, Jan 14, 2013 at 9:22 AM, Simon Perreault wrote: > Le 2013-01-14 14:14, Iljitsch van Beijnum a =E9crit : > >> However, it doesn't seem too difficult to make protocol 41 NATing >> work: simply use the embedded IPv6 destination address for >> demultiplexing. With this in place, existing IPv6-enabled home >> gateways could talk to existing tunnel brokers (tunnelbroker.net, >> sixxs.net) even though there's a carrier grade NAT in the middle. > > > BCP: don't use proto 41 behind a NAT. > > Use an IPv6 tunnelling protocol that supports NAT. > E.g.: TSP [RFC5572], which is used at freenet6.net. > > Simon > And there is also this http://tools.ietf.org/html/rfc6732 CB > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Mon Jan 14 10:38:36 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E2421F885E for ; Mon, 14 Jan 2013 10:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.515 X-Spam-Level: X-Spam-Status: No, score=-109.515 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt1z3JMX8Egp for ; Mon, 14 Jan 2013 10:38:36 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 04BD021F8828 for ; Mon, 14 Jan 2013 10:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=128; q=dns/txt; s=iport; t=1358188716; x=1359398316; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=Lc6AWwMVbtniZ20cMpxWsqVO7ClAD1zzhkjXSrIMJFs=; b=g4tM3T2h7tvAiMYk5zNKqLTLNVaXFLmWFignwTOA9JZIZrTZHnkyoxC7 GAHxfU2clYvjgMkhQpqBd5bHNNxpBOWG2gqXGqJ41Q0GONXMpVEDS/gCa /FvaYbBBeV8bQAlVg6Dx7cZkHUrjNuLHu2DIrWaMDtPziy1gSsHSvYSMi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAPtP9FCrRDoH/2dsb2JhbABEhXO0UYM1FnOCJQgCMEwFaD8BBBMLBYgIljeeS44FgykDiGGFHIgOkEmDFg X-IronPort-AV: E=Sophos;i="4.84,468,1355097600"; d="scan'208";a="68755684" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 14 Jan 2013 18:38:35 +0000 Received: from DWINGWS01 ([10.32.240.197]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0EIcQJq024427 for ; Mon, 14 Jan 2013 18:38:35 GMT From: "Dan Wing" To: Date: Mon, 14 Jan 2013 10:38:17 -0800 Message-ID: <095f01cdf286$5c88c8a0$159a59e0$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3ycyzv7B8GB8nYSD2vH4K4vUrc/w== Content-Language: en-us Subject: [BEHAVE] BEHAVE at IETF86 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 18:38:36 -0000 I requested a time slot at IETF86. Please send the chairs your agenda requests, behave-chairs@tools.ietf.org. Thanks, -d From iljitsch@muada.com Mon Jan 14 12:51:32 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0921521F8B1A for ; Mon, 14 Jan 2013 12:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwRq6o2P2qx1 for ; Mon, 14 Jan 2013 12:51:30 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 2F00121F8AE3 for ; Mon, 14 Jan 2013 12:51:30 -0800 (PST) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r0EKlIkF076222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Jan 2013 21:47:18 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: Date: Mon, 14 Jan 2013 21:51:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8A95C760-1B1B-41B0-BD4B-9F8D1791149F@muada.com> References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> <50F43ED1.4020704@viagenie.ca> To: Cameron Byrne X-Mailer: Apple Mail (2.1499) Cc: behave@ietf.org Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 20:51:32 -0000 On 14 jan 2013, at 18:23, Cameron Byrne wrote: > And there is also this http://tools.ietf.org/html/rfc6732 Wait, what? You are suggesting that ISPs not only do CGNAT for IPv4, but = also for IPv6?= From iljitsch@muada.com Mon Jan 14 12:56:26 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B660421F8AE3 for ; Mon, 14 Jan 2013 12:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRGCRqu2CdH8 for ; Mon, 14 Jan 2013 12:56:26 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id E5AF521F8859 for ; Mon, 14 Jan 2013 12:56:25 -0800 (PST) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r0EKqDes076244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Jan 2013 21:52:13 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <50F43C96.4050709@gmail.com> Date: Mon, 14 Jan 2013 21:56:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2AB10093-CC71-4964-BCE5-E966339FCFFA@muada.com> References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> <50F43C96.4050709@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1499) Cc: Wes Felter , behave@ietf.org Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 20:56:26 -0000 On 14 jan 2013, at 18:12, Brian E Carpenter = wrote: > otoh I don't think that adding this feature to a CGN is the best > use of an ISP's time. See RFC 6264. Not sure if ISPs write their own CGN code... The big selling point of protocol 41 through CGN is that it works with = unmodified home gateways and unmodified tunnel brokers. I've had = IPv6-capable home gateways since 2004 or 2005, but I'm not sure if any = of them would be able to handle native IPv6 the way it's rolled out = today (I hope to find out one of these days!), and they certainly don't = support 6rd or AYIYA or anything like that. Protocol 41 is the lingua franca of IPv6-in-IPv4 tunneling. I think it's = helpful to support it when and where possible.= From ssenthil@cisco.com Mon Jan 14 15:11:59 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF11C21F8B2F for ; Mon, 14 Jan 2013 15:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhp43kLqKarg for ; Mon, 14 Jan 2013 15:11:57 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 09AA221F8B19 for ; Mon, 14 Jan 2013 15:11:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60698; q=dns/txt; s=iport; t=1358205117; x=1359414717; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=5oQpYKEZ84tFdrjz9XLMeJLgVI9A8e6Gq8ynti/pFFg=; b=Monc/Z+2v6I5mFY1l9YgSXBM8SO3SNxJc50jSjawgUs42nVSE0WN5E75 T9I2E3g9ZuXK+inb6z+rFWwvM85z883jlQaYR/N8eimKADXdey0C0dJRg be0nPuEzcXm30eFYCMXjX0Y+BIRUJmIT6AoscEMtRlqDXOL00sjiOo9JT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFABqP9FCtJV2d/2dsb2JhbAA6AQmCSLISAYVpgzcWc4IeAQEBBBoTOhISAQgRAwEBAQsLCwEGORQJCAIEDgUIE4d+DLVjjHwBfFmBe2EDkliET48tgmgNgiQ X-IronPort-AV: E=Sophos;i="4.84,468,1355097600"; d="scan'208,217";a="162131900" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 14 Jan 2013 23:11:56 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0ENBtvE013373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jan 2013 23:11:55 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.248]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 14 Jan 2013 17:11:55 -0600 From: "Senthil Sivakumar (ssenthil)" To: Tina TSOU Thread-Topic: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 Thread-Index: AQHN6v78YP2KpbnFuU2gfgvBIZ6BeJhJk9gA Date: Mon, 14 Jan 2013 23:11:54 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.117.198.136] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D023237ABF4xmbrcdx15ciscoc_" MIME-Version: 1.0 Cc: "behave@ietf.org" , "Reinaldo Penno \(repenno\)" , Julia Renouard , "Draft-Tsou-Behave-Natx4-Log-Reduction@Tools. Ietf. Org" Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 23:12:00 -0000 --_000_CB1B483277FEC94E9B58357040EE5D023237ABF4xmbrcdx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tina, The focus of the logging draft as it exists is not to reduce the logging, i= t is a framework document that can define templates for logging in a generi= c way. As it says in section 3 "The optimization of logging the NAT events are le= ft to the implementation and are beyond the scope of this document.". We don=92t any overlap between these two documents that requires converging= /merging. Thanks Senthil From: Tina TSOU > Date: Friday, January 4, 2013 11:41 PM To: Senthil Sivakumar > Cc: Julia Renouard >, "Reinaldo= Penno (repenno)" >, "behave@ie= tf.org" >, = "Draft-Tsou-Behave-Natx4-Log-Reduction@Tools. Ietf. Org" > Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 Dear Senthil, Reinaldo et al, Draft-sivakumar does describe dynamically assign port range and take logs b= ased on port range, which overlaps much with draft-tsou-behave-natx4-log-re= duction. http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-05#section-4.= 4.9 describes allocating and retrieving port range, but it is not clear whe= ther one user can have multiple port range, or only one. Though the focus of this draft is not how to allocate port range, only ment= ions what content in the recorded information. This draft currently only supports continuous port range, not non-continuou= s one. So I propose these two drafts converge. Thank you, Tina On Jan 4, 2013, at 6:49 AM, "Senthil Sivakumar (ssenthil)" > wrote: From: Julia Renouard > Date: Wednesday, January 2, 2013 9:05 PM To: Senthil Sivakumar >, "Rei= naldo Penno (repenno)" >, "beha= ve@ietf.org" > Subject: RE: Comments on draft-sivakumar-behave-nat-logging-05 Hi Senthil =96 Nice fast turn-around. So part of my confusion here appears= to be derived from your opening sentence in the Abstract and Scope section= s: =93This document provides the information model to be used for logging= the Carrier Grade NAT (CGN) events.=94 So you might want to clarify the = scope as well if this is intended to be broader than CGN. :) My apologies= that I did not review the history of this draft. I started with this for = review =96 a bit in a vacuum I admit. [Senthil] Right, the sentence after the first one says "The logs are requir= ed in many cases to identify an attacker or a host that was used to launch = malicious attacks and/or for various other purposes of accounting.", which = is not specific to CGN. But I agree, it might have been misleading. I will = do some wordsmithing to clarify this better. A follow up thought, if this is intended to be for all NAT types, including= generic NAT and CGN, not paying attention to minimizing logging and the ba= ndwidth and data constraints of the CGN deployments will end up making most= CGN devices to only be partially compliant if the recommendations laid out= here remain a SHOULD or do not take this need into account. We will simpl= y have to use it as high-level guidance and take our own path because minim= izing logging is a requirement for us. Even so, I think it will still be u= seful to identify the common use-cases for logging. This helps better revi= ew if the recommendations you are making achieve those goals or not. [Senthil] The templates and the framework are generic enough that would be = applicable to both. For the log reduction, there are already a couple of dr= afts that talks about ways to do that. On the question of the generic vs specific natEvent enumerations, I actuall= y feel the generic is more extensible, but yes, I agree =96 broader WG opin= ions should be sought and to be honest I have not compared it with other IE= =92s for consistency nor looked at IPFIX collector implementations. My con= cern is as much from a =93best practice=94 of data hiding =96 where events = are generic and type is part of data. This facilitates extensibility and f= uture proofing implementations. The example of the error enumeration is a = good one. As a collector, I can implement to recognize a generic =93Trans= lation error=94 event =96 and I don=92t need to update my software for ever= y new error type that comes along. I know I will catch it. I may not know= what type of error but I will know an error occurred. As for the generic = NAT events vs. specific type-encoded events, yes I understand the goal of h= aving the nat type. You could provide the additional natType IE in the tem= plate but, as you say, that is an additional byte. However IMHO the value = of extensibility outweighs this. In order to add NAT66, for example, you n= ow need to extend this yet again. Not having implemented an IPFIX collec= tor I cannot speak to whether this addition of the NAT type actually resolv= es any ambiguity that the different templates would not. (sourceIPv6Addres= s vs. IPv4). I=92d have to look back in the threads for the feedback on DS-Lite to under= stand the concerns wrt this draft, but as an implementer it is something I = have to solve. I don=92t think it requires any new types. But I think it = would be useful to offer template guidance. For us, we were intending simp= ly to use a sourceIPv6Address IE (consistent with Section 4 in behave-lsn-r= equirements). Optionally we may also include a sourceIPv4Address if the cu= stomer desired. Again, I don=92t think it needs its own IE=92s or types, j= ust template guidance and how this will be interpreted commonly by collecto= rs. Just a thought=85 Thanks again =96 we look forward to the next round. I appreciate your work= here, Julia Thanks Senthil From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] Sent: Wednesday, January 02, 2013 4:14 PM To: Julia Renouard; Reinaldo Penno (repenno); behave@ietf.org Subject: Re: Comments on draft-sivakumar-behave-nat-logging-05 Hi Julia, Thanks for the comments. Please see inline. From: Julia Renouard > Date: Wednesday, January 2, 2013 5:28 PM To: "Reinaldo Penno (repenno)" = >, Senthil Sivakumar >, "beha= ve@ietf.org" > Subject: Comments on draft-sivakumar-behave-nat-logging-05 Hi Reinaldo & Senthil =96 Thank you for your work here. I know this has been through a few iteration= s . I do think this is needed minimally as guidance. This was the only t= hing we found, save for section 4 in behave-lsn-requirements that gave guid= ance on CGN logging. And your justification is spot-on. Now for feedback= =85 Summary: First, we are very concerned about the re-enumeration of natEvent values in= section 4.2. It is not good practice and is disruptive to implementers to= re-enumerate published values. Also the values created here are too speci= fic and make this not-easily extended. The only exception I might make h= ere is to change the existing "Pool Exhausted" value to be "Translation Fai= lure" or simply add a new enum for this. I think generic events are better= than specific. More on this below. [Senthil] I assume you mean the IPFIX IANA assigned values for natEvents. Y= ou are right, there is an inconsistency between the two. As you pointed out= , the create and delete event is consistent with the IPFIX values, we need = to add the poolExhausted value in the draft or create a new value for it. = We will do it as part of the next rev. I would like to see this draft reference and be consistent with draft-ietf-= behave-lsn-requirements-x which does describe, in section 4, logging requir= ements for a CGN. I think this document needs align with the logging requi= rements here in the overall goals and constraints. Namely, the primary goa= l for NAT logging is to enable the ability to identify a subscriber - often= for legal reasons. The constraint that we need to be mindful of is loggin= g resource consumption. Many CGN features are specifically designed to min= imize log size while still maintaining the ability to identify subscribers = - Port block allocation for example. [Senthil] This document is not just for CGN logging, it is a generic NAT lo= gging document that can be used also for satisfying CGN logging requirement= s. As mentioned in the scope, the optimization of log events (size, the way= you pack the records etc) is not within the scope of this document. There = are many other documents that provide solutions for that. The main purpose = of this document is to provide a framework and a template to log NAT events= =96 that both the NAT vendors and the collector vendors can use to interop= erate. CGN logging for the purposes of identifying subscribers and with the goal o= f minimizing data consumption, needs to focus on the NAT translations (bind= ings) and be as minimalistic as possible. Flow logging or session logging = has a different purpose - statistical, data usage analysis, quality analysi= s, security, billing=85 There may be some overlap of use-cases but this do= cument doesn't really speak to them. It might be interesting to look at ty= pical/traditional NetFlow/IPFIX Flow logging and see how that might be diff= erent for a NAT. But there are at least 2 different use-cases - if this d= ocument wants to address both, I think it would be useful to distinguish th= em. But flow/session logging needs to be discrete because administrators m= ay only choose translation logging for data conservation purposes. It seem= s to me that your session create/delete events fall into this camp, althoug= h I=92m interested in your intent here. Minimally I=92d be interested in a= comparison. [Senthil] Just to re-iterate, the focus of the draft is generic NAT logging= =96 not just CGN. The NAT templates defined in the draft is generic enough= to cover both CGN and non-CGN NAT logging. I am not really sure I understa= nd the gist of the above paragraph, but flow logging is being used for data= retention purposes. Again our intention here is have a generic logging fra= mework. My high level recommendations: 1. Don't renumber IANA defined enums. Reasons cited above. [Senthil] Ok. But a lot of what is defined here is what went on to become I= ANA values, but your point is well taken, we will get rid of inconsistencie= s. 2. Keep high level events generic. This makes them more extensible. = "Create", "Delete" and "Translation Failure" - with more data as additiona= l (optional) IE's. For example, keeping the "error" event generic allows c= ollectors to universally identify an error, even as more error types are cr= eated. [Senthil] The problem is if we have a simple create, delete, we wont be abl= e to distinguish what kind of an nat this is =96 nat44, nat64 etc. For us t= o add additional data, that would cause us to have another byte. In this ca= se, we can have a max of 256 types (with 8 bits) and hence make sense to pr= esent the information in one shot. I am open to suggestions here but would = like some WG guidance. 3. Be careful about error logging recommendations. I would set these= as MAY with comments about limiting how often these are emitted in a pool = exhaustion case so as not to DoS the source or target system. [Senthil] Agreed. 4. Consider DSLite in your recommendations - what IE's should be used= to report a DSLite subscriber? [Senthil] We had DS lite in earlier revision of the draft in -03. But the W= G wanted us to keep it specifically to NAT, so the latest versions got rid = of them. 5. Make the Port Block Allocation extensions part of the "Create" and= "Delete" event templates. [Senthil] Ok. 6. Call out specifically which IE's are new. Section 7 is not comple= te or accurate. portRange* ID's have been defined. You also have IE's ide= ntified which do not exist and are not called out in section 7. [Senthil] Ok. 7. Section 4 - Event based Logging: "Each of these events SHOULD be = logged, unless they are administratively prohibited" - This is a problemati= c recommendation and is contrary to the need to minimize logging (i.e. logg= ing every session ) [Senthil] As I clarified above, minimizing logging is not a goal of this dr= aft. 8. Bring this into alignment with draft-behave-lsn-requirements. E.= g. REQ-12. Destination addresses SHOULD NOT be logged. That said, a mappin= g event MAY have a destination address if administrator requires it. In wh= ich case I would recommend only 1 IE - destinationIPxAddress or postNATDest= inationIPvxAddress - both seems redundant. [Senthil] I think we can add some text around this, that if the CGN is runn= ing, then destination address should not be logged. 9. Separate out session logging from translation logging. Session lo= gging bloats the data set and is unnecessary just for identifying subscribe= rs 10. Describe the difference between session logging and BIB(translation) = logging and when to use them. IMHO session logging looks a lot more like f= low logging. I'd be interested in a description of the differences and a s= eparate of the two cases. Perhaps flow logging for NAT's is a separate use= -case. [Senthil] As explained above, for 9 & 10, this is a generic draft. 11. Look at using natPoolName optionally in more events - I think it will= be useful, minimally for errors [Senthil] Ok. 12. Can we find an IE to send a "subscriber identity"? I'm wondering abo= ut #371, "userName" - for a mobile service provider this might actually be = an IMSI or IMEI numbers. This would be optional. [Senthil] I will check, the last time I checked there were a couple of fiel= ds that could be used. 13. Be mindful of the need for data conservation and to minimize logging = in your MUST and SHOULD requirements. MUST and SHOULD requirements should = be minimalistic to achieve the base use-case and nothing more. E.g. look t= o the data elements identified in behave-lsn-requirements. But ideally it = also gives guidance on some typical use-cases and how to achieve them. [Senthil] Minimizing the logging is not the goal of this draft. One more nit: [NAT-EVENT-LOG-IANA] - this link does not exist. You shoul= d update this to be the IANA IPFIX IE registry. [Senthil] Ok, thanks. Thanks again for this. I hope this feedback is helpful. We look forward t= o the next draft. [Senthil] Thanks for the helpful comments. Will incorporate the relevant on= es. Senthil Happy New Year, Julia Renouard --_000_CB1B483277FEC94E9B58357040EE5D023237ABF4xmbrcdx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3EF054C0C27A37489025E2299A02FF1F@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Tina,
The focus of the logging draft as it exists is not to reduce the logging, i= t is a framework document that can define templates for logging in a generi= c way.
As it says in  section 3 "The optimization of logging the NAT events are left to the implementation and are beyond the scope of = this document.".
We don=92t any overlap between these two documents that requires conve= rging/merging.

Thanks
Senthil

From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
Date: Friday, January 4, 2013 11:41= PM
To: Senthil Sivakumar <ssenthil@cisco.com>
Cc: Julia Renouard <J.Renouard@F5.com>, "Reinaldo Penno (r= epenno)" <repenno@cisco.com>, "behave@ietf.org" <behave@ietf.org>, "Draf= t-Tsou-Behave-Natx4-Log-Reduction@Tools. Ietf. Org" <draft-tsou-behave= -natx4-log-reduction@tools.ietf.org>
Subject: Re: [BEHAVE] Comments on d= raft-sivakumar-behave-nat-logging-05

Dear Senthil, Reinaldo et al,
Draft-sivakumar does describe dynamically assign port range and take l= ogs based on port range, which overlaps much with draft-tsou-behave-natx4-l= og-reduction.

 

http://tools.ietf.org/html/draft-siv= akumar-behave-nat-logging-05#section-4.4.9 describes allocating and retrieving port range, but it is not clear whether one user= can have multiple port range, or only one.

 

Though the focus of this draft is not = how to allocate port range, only mentions what content in the recorded info= rmation. 

This draft currently only supports con= tinuous port range, not non-continuous one.


So I propose these two drafts converge= .


Thank you,
Tina

On Jan 4, 2013, at 6:49 AM, "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com> wrote:



From: Julia Renouard <J.Renouard@F5.com>
Date: Wednesday, January 2, 2013 9:= 05 PM
To: Senthil Sivakumar <ssenthil@cisco.com>, "Reinaldo P= enno (repenno)" <repenno@cisco= .com>, "behave@ietf.org&= quot; <behave@ietf.org>
Subject: RE: Comments on draft-siva= kumar-behave-nat-logging-05

Hi Senthil =96 Nice fa= st turn-around.  So part of my confusion here appears to be derived fr= om your opening sentence in the Abstract and Scope sections:   = =93This document provides the information model to be used for logging the Carrier Grade NAT (CGN) events.=94   So you migh= t want to clarify the scope as well if this is intended to be broader than = CGN.  J  My apologies that I did not review the history= of this draft.  I started with this for review =96 a bit in a vacuum = I admit.

[Senthil] Right, the sentence after = the first one says "The logs are required in many = cases to identify an attacker or a host that was used to launch malicious attacks and/o= r for various other purposes of accounting.", which is not specific to= CGN. But I agree, it might have been misleading. I

 

A follow up thought, i= f this is intended to be for all NAT types, including generic NAT and CGN, = not paying attention to minimizing logging and the bandwidth and data const= raints of the CGN deployments will end up making most CGN devices to only be partially compliant if the recommend= ations laid out here remain a SHOULD or do not take this need into account.=   We will simply have to use it as high-level guidance and take our ow= n path because minimizing logging is a requirement for us.  Even so, I think it will still be useful to id= entify the common use-cases for logging.  This helps better review if = the recommendations you are making achieve those goals or not.

[Senthil] The templates and the framework are generic enough that woul= d be applicable to both. For the log reduction, there are already a couple = of drafts that talks about ways to do that.

 

On the question of the= generic vs specific natEvent enumerations, I actually feel the generic is = more extensible, but yes, I agree =96 broader WG opinions should be sought = and to be honest I have not compared it with other IE=92s for consistency nor looked at IPFIX collector implementa= tions.  My concern is as much from a =93best practice=94 of data hidin= g =96 where events are generic and type is part of data.  This facilit= ates extensibility and future proofing implementations.  The example of the error enumeration is a good one.  As a colle= ctor, I can implement to recognize a generic  =93Translation error=94 = event =96 and I don=92t need to update my software for every new error type= that comes along.  I know I will catch it.  I may not know what type of error but I will know an error occurred.  As for th= e generic NAT events vs. specific type-encoded events, yes I understand the= goal of having the nat type.  You could provide the additional natTyp= e IE in the template but, as you say, that is an additional byte.  However IMHO the value of extensibility outwe= ighs this.  In order to add NAT66, for example, you now need to extend= this yet again.    Not having implemented an IPFIX collecto= r I cannot speak to whether this addition of the NAT type actually resolves any ambiguity that the different templates would not.&nb= sp; (sourceIPv6Address vs. IPv4).    

 

I=92d have to look bac= k in the threads for the feedback on DS-Lite to understand the concerns wrt= this draft, but as an implementer it is something I have to solve.  I= don=92t think it requires any new types.  But I think it would be useful to offer template guidance.  For us, we we= re intending simply to use a sourceIPv6Address IE (consistent with Section = 4 in behave-lsn-requirements).  Optionally we may also include a sourc= eIPv4Address if the customer desired.  Again, I don=92t think it needs its own IE=92s or types, just template guidance a= nd how this will be interpreted commonly by collectors.  Just a though= t=85

 

Thanks again =96 we lo= ok forward to the next round.  I appreciate your work here,=

Julia

 
Thanks
Senthil

 

From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com]
Sent: Wednesday, January 02, 2013 4:14 PM
To: Julia Renouard; Reinaldo Penno (repenno); behave@ietf.org
Subject: Re: Comments on draft-sivakumar-behave-nat-logging-05 =

 

Hi Juli= a,

Thanks = for the comments. Please see inline.

&n= bsp;

From: Julia Renouard <J.Renouard@F5.com>
Date: Wednesday, January 2, 2013 5:28 PM
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>, Senthil Sivakumar <ssenthil@cisco.com>, "behave@ietf.org" <behave@ietf.org>
Subject: Comments on draft-sivakumar-behave-nat-logging-05

&n= bsp;

Hi Reinaldo & Senthil =96

 

Thank you for your work here.  I know this has been through a few = iterations .  I do think this is needed minimally as guidance. &n= bsp; This was the only thing we found, save for section 4 in behave-lsn-requirements that gave guidance on CGN logging.  And yo= ur justification is spot-on.   Now for feedback=85

  

Summary:

First, we are very concerned about the re-enumeration of natEvent value= s in section 4.2.  It is not good practice and is disruptive to implem= enters to re-enumerate published values.  Also the values created here are too specific and make this not-easily extended= .    The only exception I might make here is to change the e= xisting "Pool Exhausted" value to be "Translation Failure&qu= ot; or simply add a new enum for this.  I think generic events are better than specific.  More on this below.

&n= bsp;

[Senthi= l] I assume you mean the IPFIX IANA assigned values for natEvents. You are = right, there is an inconsistency between the two. As you pointed out, the c= reate and delete event is consistent with the IPFIX values, we need to add the poolExhausted value in the draft= or create a new value for it.  We will do it as part of the next rev.=  

 

I would like to see this draft reference and be consistent with draft-i= etf-behave-lsn-requirements-x which does describe, in section 4, logging re= quirements for a CGN.  I think this document needs align with the logging requirements here in the overall goals and co= nstraints.  Namely, the primary goal for NAT logging is to enable the = ability to identify a subscriber - often for legal reasons.  The const= raint that we need to be mindful of is logging resource consumption.  Many CGN features are specifically designed to= minimize log size while still maintaining the ability to identify subscrib= ers - Port block allocation for example.

&n= bsp;

[Senthi= l] This document is not just for CGN logging, it is a generic NAT logging d= ocument that can be used also for satisfying CGN logging requirements. As m= entioned in the scope, the optimization of log events (size, the way you pack the records etc) is not within the s= cope of this document. There are many other documents that provide solution= s for that. The main purpose of this document is to provide a framework and= a template to log NAT events =96 that both the NAT vendors and the collector vendors can use to interoperat= e.

 

CGN logging for the purposes of identifying subscribers and with the go= al of minimizing data consumption, needs to focus on the NAT translations (= bindings) and be as minimalistic as possible.  Flow logging or session logging has a different purpose - statistical, dat= a usage analysis, quality analysis, security, billing=85  There may be= some overlap of use-cases but this document doesn't really speak to them.&= nbsp; It might be interesting to look at typical/traditional NetFlow/IPFIX Flow logging and see how that might be different for a NAT.&= nbsp;  But there are at least 2 different use-cases - if this document= wants to address both, I think it would be useful to distinguish them.&nbs= p; But flow/session logging needs to be discrete because administrators may only choose translation logging for data conser= vation purposes.  It seems to me that your session create/delete event= s fall into this camp, although I=92m interested in your intent here. = Minimally I=92d be interested in a comparison.

&n= bsp;

[Senthi= l] Just to re-iterate, the focus of the draft is generic NAT logging =96 no= t just CGN. The NAT templates defined in the draft is generic enough to cov= er both CGN and non-CGN NAT logging. I am not really sure I understand the gist of the above paragraph, but flow = logging is being used for data retention purposes. Again our intention here= is have a generic logging framework. 

 <= o:p>

 

My high level recommendations:

1.       Don't renumb= er IANA defined enums.  Reasons cited above. 

&n= bsp;

[Senthi= l] Ok. But a lot of what is defined here is what went on to become IANA val= ues, but your point is well taken, we will get rid of inconsistencies.=

&n= bsp;

2.       Keep high le= vel events generic.  This makes them more extensible.  "Crea= te", "Delete" and "Translation Failure" - with mor= e data as additional (optional) IE's.  For example, keeping the "= error" event generic allows collectors to universally identify an error, even as more e= rror types are created. 

[Senthi= l] The problem is if we have a simple create, delete, we wont be able to di= stinguish what kind of an nat this is =96 nat44, nat64 etc. For us to add a= dditional data, that would cause us to have another byte. In this case, we can have a max of 256 types (with 8 bi= ts) and hence make sense to present the information in one shot. I am open = to suggestions here but would like some WG guidance.

&n= bsp;

3.       Be careful a= bout error logging recommendations.  I would set these as MAY with com= ments about limiting how often these are emitted in a pool exhaustion case = so as not to DoS the source or target system. 

[Senthi= l] Agreed. 

&n= bsp;

4.       Consider DSL= ite in your recommendations - what IE's should be used to report a DSLite s= ubscriber? 

&n= bsp;

[Senthi= l] We had DS lite in earlier revision of the draft in -03. But the WG wante= d us to keep it specifically to NAT, so the latest versions got rid of them= .

&n= bsp;

5.       Make the Por= t Block Allocation extensions part of the "Create" and "Dele= te" event templates.

[Senthi= l] Ok.

6.       Call out spe= cifically which IE's are new.  Section 7 is not complete or accurate.&= nbsp; portRange* ID's have been defined.  You also have IE's identifie= d which do not exist and are not called out in section 7.

[Senthi= l] Ok.

7.       Section 4 - = Event based Logging:  "Each of these events SHOULD be logged, unl= ess they are administratively prohibited" - This is a problematic reco= mmendation and is contrary to the need to minimize logging (i.e. logging every session )

[Senthi= l] As I clarified above, minimizing logging is not a goal of this draft.

&n= bsp;

8.       Bring this i= nto alignment with draft-behave-lsn-requirements.   E.g. REQ-12. = Destination addresses SHOULD NOT be logged.  That said, a mapping even= t MAY have a destination address if administrator requires it.  In which case I would recommend only 1 IE - destination= IPxAddress or postNATDestinationIPvxAddress - both seems redundant.

[Senthi= l] I think we can add some text around this, that if the CGN is running, th= en destination address should not be logged.

&n= bsp;

9.       Separate out= session logging from translation logging.  Session logging bloats the= data set and is unnecessary just for identifying subscribers

&n= bsp;

&n= bsp;

10.   Describe the= difference between session logging and BIB(translation) logging and when t= o use them.  IMHO session logging looks a lot more like flow logging.&= nbsp; I'd be interested in a description of the differences and a separate of the two cases.  Perhaps flow loggin= g for NAT's is a separate use-case. 

[Senthi= l] As explained above, for 9 & 10, this is a generic draft.<= /span>

11.   Look at usin= g natPoolName optionally in more events - I think it will be useful, minima= lly for errors

&n= bsp;

[Senthi= l] Ok.

12.   Can we find = an IE to send a "subscriber identity"?  I'm wondering about = #371, "userName" - for a mobile service provider this might actua= lly be an IMSI or IMEI numbers.  This would be optional.

[Senthi= l] I will check, the last time I checked there were a couple of fields that= could be used.  

&n= bsp;

13.   Be mindful o= f the need for data conservation and to minimize logging in your MUST and S= HOULD requirements.  MUST and SHOULD requirements should be minimalist= ic to achieve the base use-case and nothing more.  E.g. look to the data elements identified in behave-lsn-requir= ements.  But ideally it also gives guidance on some typical use-cases = and how to achieve them.

&n= bsp;

[Senthi= l] Minimizing the logging is not the goal of this draft.<= /p>

 

 

One more nit:  = ; [NAT-EVENT-LOG-IANA] - this link does not exist.  You should update = this to be the IANA IPFIX IE registry.

&n= bsp;

[Senthi= l] Ok, thanks.

 

 

Thanks again for this.&n= bsp; I hope this feedback is helpful.  We look forward to the next dra= ft.

 =

[Senthi= l] Thanks for the helpful comments. Will incorporate the relevant ones.

&n= bsp;

Senthil=

&n= bsp;

Happy New Year,

 =

Julia Renouard

 --_000_CB1B483277FEC94E9B58357040EE5D023237ABF4xmbrcdx15ciscoc_-- From Tina.Tsou.Zouting@huawei.com Mon Jan 14 15:17:08 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DB821F8B2F for ; Mon, 14 Jan 2013 15:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgTbQ1P8FP21 for ; Mon, 14 Jan 2013 15:17:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 454F221F8B2E for ; Mon, 14 Jan 2013 15:17:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANN70925; Mon, 14 Jan 2013 23:17:04 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Jan 2013 23:16:57 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Jan 2013 23:17:02 +0000 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.156]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Mon, 14 Jan 2013 15:16:56 -0800 From: Tina TSOU To: "Senthil Sivakumar (ssenthil)" Thread-Topic: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 Thread-Index: Ac3pM+wgT/qoVm2nTy6+PuaNjoLN5QAG6DQAAAApXdAAULiMgAAa+KQdAfwocAD//3tLgA== Date: Mon, 14 Jan 2013 23:16:55 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CED6B1CEE368400E99CCB8BD9DAB8554huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Reinaldo Penno \(repenno\)" , "behave@ietf.org" , Julia Renouard , "Draft-Tsou-Behave-Natx4-Log-Reduction@Tools. Ietf. Org" Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 23:17:09 -0000 --_000_CED6B1CEE368400E99CCB8BD9DAB8554huaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Senthil, I was talking about the allocating and retrieving port range, not the whole= document. Can section 4.4.9 of draft-Sivakumar reference draft-tsou? Thank you, Tina On Jan 14, 2013, at 3:12 PM, "Senthil Sivakumar (ssenthil)" > wrote: Hi Tina, The focus of the logging draft as it exists is not to reduce the logging, i= t is a framework document that can define templates for logging in a generi= c way. As it says in section 3 "The optimization of logging the NAT events are le= ft to the implementation and are beyond the scope of this document.". We don=92t any overlap between these two documents that requires converging= /merging. Thanks Senthil From: Tina TSOU > Date: Friday, January 4, 2013 11:41 PM To: Senthil Sivakumar > Cc: Julia Renouard >, "Reinaldo= Penno (repenno)" >, "behave@ie= tf.org" >, = "Draft-Tsou-Behave-Natx4-Log-Reduction@Tools. Ietf. Org" > Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 Dear Senthil, Reinaldo et al, Draft-sivakumar does describe dynamically assign port range and take logs b= ased on port range, which overlaps much with draft-tsou-behave-natx4-log-re= duction. http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-05#section-4.= 4.9 describes allocating and retrieving port range, but it is not clear whe= ther one user can have multiple port range, or only one. Though the focus of this draft is not how to allocate port range, only ment= ions what content in the recorded information. This draft currently only supports continuous port range, not non-continuou= s one. So I propose these two drafts converge. Thank you, Tina On Jan 4, 2013, at 6:49 AM, "Senthil Sivakumar (ssenthil)" > wrote: From: Julia Renouard > Date: Wednesday, January 2, 2013 9:05 PM To: Senthil Sivakumar >, "Rei= naldo Penno (repenno)" >, "beha= ve@ietf.org" > Subject: RE: Comments on draft-sivakumar-behave-nat-logging-05 Hi Senthil =96 Nice fast turn-around. So part of my confusion here appears= to be derived from your opening sentence in the Abstract and Scope section= s: =93This document provides the information model to be used for logging= the Carrier Grade NAT (CGN) events.=94 So you might want to clarify the = scope as well if this is intended to be broader than CGN. :) My apologies= that I did not review the history of this draft. I started with this for = review =96 a bit in a vacuum I admit. [Senthil] Right, the sentence after the first one says "The logs are requir= ed in many cases to identify an attacker or a host that was used to launch = malicious attacks and/or for various other purposes of accounting.", which = is not specific to CGN. But I agree, it might have been misleading. I will = do some wordsmithing to clarify this better. A follow up thought, if this is intended to be for all NAT types, including= generic NAT and CGN, not paying attention to minimizing logging and the ba= ndwidth and data constraints of the CGN deployments will end up making most= CGN devices to only be partially compliant if the recommendations laid out= here remain a SHOULD or do not take this need into account. We will simpl= y have to use it as high-level guidance and take our own path because minim= izing logging is a requirement for us. Even so, I think it will still be u= seful to identify the common use-cases for logging. This helps better revi= ew if the recommendations you are making achieve those goals or not. [Senthil] The templates and the framework are generic enough that would be = applicable to both. For the log reduction, there are already a couple of dr= afts that talks about ways to do that. On the question of the generic vs specific natEvent enumerations, I actuall= y feel the generic is more extensible, but yes, I agree =96 broader WG opin= ions should be sought and to be honest I have not compared it with other IE= =92s for consistency nor looked at IPFIX collector implementations. My con= cern is as much from a =93best practice=94 of data hiding =96 where events = are generic and type is part of data. This facilitates extensibility and f= uture proofing implementations. The example of the error enumeration is a = good one. As a collector, I can implement to recognize a generic =93Trans= lation error=94 event =96 and I don=92t need to update my software for ever= y new error type that comes along. I know I will catch it. I may not know= what type of error but I will know an error occurred. As for the generic = NAT events vs. specific type-encoded events, yes I understand the goal of h= aving the nat type. You could provide the additional natType IE in the tem= plate but, as you say, that is an additional byte. However IMHO the value = of extensibility outweighs this. In order to add NAT66, for example, you n= ow need to extend this yet again. Not having implemented an IPFIX collec= tor I cannot speak to whether this addition of the NAT type actually resolv= es any ambiguity that the different templates would not. (sourceIPv6Addres= s vs. IPv4). I=92d have to look back in the threads for the feedback on DS-Lite to under= stand the concerns wrt this draft, but as an implementer it is something I = have to solve. I don=92t think it requires any new types. But I think it = would be useful to offer template guidance. For us, we were intending simp= ly to use a sourceIPv6Address IE (consistent with Section 4 in behave-lsn-r= equirements). Optionally we may also include a sourceIPv4Address if the cu= stomer desired. Again, I don=92t think it needs its own IE=92s or types, j= ust template guidance and how this will be interpreted commonly by collecto= rs. Just a thought=85 Thanks again =96 we look forward to the next round. I appreciate your work= here, Julia Thanks Senthil From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] Sent: Wednesday, January 02, 2013 4:14 PM To: Julia Renouard; Reinaldo Penno (repenno); behave@ietf.org Subject: Re: Comments on draft-sivakumar-behave-nat-logging-05 Hi Julia, Thanks for the comments. Please see inline. From: Julia Renouard > Date: Wednesday, January 2, 2013 5:28 PM To: "Reinaldo Penno (repenno)" = >, Senthil Sivakumar >, "beha= ve@ietf.org" > Subject: Comments on draft-sivakumar-behave-nat-logging-05 Hi Reinaldo & Senthil =96 Thank you for your work here. I know this has been through a few iteration= s . I do think this is needed minimally as guidance. This was the only t= hing we found, save for section 4 in behave-lsn-requirements that gave guid= ance on CGN logging. And your justification is spot-on. Now for feedback= =85 Summary: First, we are very concerned about the re-enumeration of natEvent values in= section 4.2. It is not good practice and is disruptive to implementers to= re-enumerate published values. Also the values created here are too speci= fic and make this not-easily extended. The only exception I might make h= ere is to change the existing "Pool Exhausted" value to be "Translation Fai= lure" or simply add a new enum for this. I think generic events are better= than specific. More on this below. [Senthil] I assume you mean the IPFIX IANA assigned values for natEvents. Y= ou are right, there is an inconsistency between the two. As you pointed out= , the create and delete event is consistent with the IPFIX values, we need = to add the poolExhausted value in the draft or create a new value for it. = We will do it as part of the next rev. I would like to see this draft reference and be consistent with draft-ietf-= behave-lsn-requirements-x which does describe, in section 4, logging requir= ements for a CGN. I think this document needs align with the logging requi= rements here in the overall goals and constraints. Namely, the primary goa= l for NAT logging is to enable the ability to identify a subscriber - often= for legal reasons. The constraint that we need to be mindful of is loggin= g resource consumption. Many CGN features are specifically designed to min= imize log size while still maintaining the ability to identify subscribers = - Port block allocation for example. [Senthil] This document is not just for CGN logging, it is a generic NAT lo= gging document that can be used also for satisfying CGN logging requirement= s. As mentioned in the scope, the optimization of log events (size, the way= you pack the records etc) is not within the scope of this document. There = are many other documents that provide solutions for that. The main purpose = of this document is to provide a framework and a template to log NAT events= =96 that both the NAT vendors and the collector vendors can use to interop= erate. CGN logging for the purposes of identifying subscribers and with the goal o= f minimizing data consumption, needs to focus on the NAT translations (bind= ings) and be as minimalistic as possible. Flow logging or session logging = has a different purpose - statistical, data usage analysis, quality analysi= s, security, billing=85 There may be some overlap of use-cases but this do= cument doesn't really speak to them. It might be interesting to look at ty= pical/traditional NetFlow/IPFIX Flow logging and see how that might be diff= erent for a NAT. But there are at least 2 different use-cases - if this d= ocument wants to address both, I think it would be useful to distinguish th= em. But flow/session logging needs to be discrete because administrators m= ay only choose translation logging for data conservation purposes. It seem= s to me that your session create/delete events fall into this camp, althoug= h I=92m interested in your intent here. Minimally I=92d be interested in a= comparison. [Senthil] Just to re-iterate, the focus of the draft is generic NAT logging= =96 not just CGN. The NAT templates defined in the draft is generic enough= to cover both CGN and non-CGN NAT logging. I am not really sure I understa= nd the gist of the above paragraph, but flow logging is being used for data= retention purposes. Again our intention here is have a generic logging fra= mework. My high level recommendations: 1. Don't renumber IANA defined enums. Reasons cited above. [Senthil] Ok. But a lot of what is defined here is what went on to become I= ANA values, but your point is well taken, we will get rid of inconsistencie= s. 2. Keep high level events generic. This makes them more extensible. = "Create", "Delete" and "Translation Failure" - with more data as additiona= l (optional) IE's. For example, keeping the "error" event generic allows c= ollectors to universally identify an error, even as more error types are cr= eated. [Senthil] The problem is if we have a simple create, delete, we wont be abl= e to distinguish what kind of an nat this is =96 nat44, nat64 etc. For us t= o add additional data, that would cause us to have another byte. In this ca= se, we can have a max of 256 types (with 8 bits) and hence make sense to pr= esent the information in one shot. I am open to suggestions here but would = like some WG guidance. 3. Be careful about error logging recommendations. I would set these= as MAY with comments about limiting how often these are emitted in a pool = exhaustion case so as not to DoS the source or target system. [Senthil] Agreed. 4. Consider DSLite in your recommendations - what IE's should be used= to report a DSLite subscriber? [Senthil] We had DS lite in earlier revision of the draft in -03. But the W= G wanted us to keep it specifically to NAT, so the latest versions got rid = of them. 5. Make the Port Block Allocation extensions part of the "Create" and= "Delete" event templates. [Senthil] Ok. 6. Call out specifically which IE's are new. Section 7 is not comple= te or accurate. portRange* ID's have been defined. You also have IE's ide= ntified which do not exist and are not called out in section 7. [Senthil] Ok. 7. Section 4 - Event based Logging: "Each of these events SHOULD be = logged, unless they are administratively prohibited" - This is a problemati= c recommendation and is contrary to the need to minimize logging (i.e. logg= ing every session ) [Senthil] As I clarified above, minimizing logging is not a goal of this dr= aft. 8. Bring this into alignment with draft-behave-lsn-requirements. E.= g. REQ-12. Destination addresses SHOULD NOT be logged. That said, a mappin= g event MAY have a destination address if administrator requires it. In wh= ich case I would recommend only 1 IE - destinationIPxAddress or postNATDest= inationIPvxAddress - both seems redundant. [Senthil] I think we can add some text around this, that if the CGN is runn= ing, then destination address should not be logged. 9. Separate out session logging from translation logging. Session lo= gging bloats the data set and is unnecessary just for identifying subscribe= rs 10. Describe the difference between session logging and BIB(translation) = logging and when to use them. IMHO session logging looks a lot more like f= low logging. I'd be interested in a description of the differences and a s= eparate of the two cases. Perhaps flow logging for NAT's is a separate use= -case. [Senthil] As explained above, for 9 & 10, this is a generic draft. 11. Look at using natPoolName optionally in more events - I think it will= be useful, minimally for errors [Senthil] Ok. 12. Can we find an IE to send a "subscriber identity"? I'm wondering abo= ut #371, "userName" - for a mobile service provider this might actually be = an IMSI or IMEI numbers. This would be optional. [Senthil] I will check, the last time I checked there were a couple of fiel= ds that could be used. 13. Be mindful of the need for data conservation and to minimize logging = in your MUST and SHOULD requirements. MUST and SHOULD requirements should = be minimalistic to achieve the base use-case and nothing more. E.g. look t= o the data elements identified in behave-lsn-requirements. But ideally it = also gives guidance on some typical use-cases and how to achieve them. [Senthil] Minimizing the logging is not the goal of this draft. One more nit: [NAT-EVENT-LOG-IANA] - this link does not exist. You shoul= d update this to be the IANA IPFIX IE registry. [Senthil] Ok, thanks. Thanks again for this. I hope this feedback is helpful. We look forward t= o the next draft. [Senthil] Thanks for the helpful comments. Will incorporate the relevant on= es. Senthil Happy New Year, Julia Renouard --_000_CED6B1CEE368400E99CCB8BD9DAB8554huaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dear Senthil,
I was talking about the allocating and retrieving port range, not the whole document.
Can section 4.4.9 of draft-Sivakumar reference draft-tsou?

Thank you,
Tina

On Jan 14, 2013, at 3:12 PM, "Senthil Sivakumar (ssenthil)" <<= a href=3D"mailto:ssenthil@cisco.com">ssenthil@cisco.com> wrote:

Hi Tina,
The focus of the logging draft as it exists is not to reduce the logging, i= t is a framework document that can define templates for logging in a generi= c way.
As it says in  section 3 "The optimization of logging the NAT events are left to the implementation and are beyond the scope of = this document.".
We don=92t any overlap between these two documents that requires conve= rging/merging.

Thanks
Senthil

From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
Date: Friday, January 4, 2013 11:41= PM
To: Senthil Sivakumar <ssenthil@cisco.com>
Cc: Julia Renouard <J.Renouard@F5.com>, "Reinaldo Penno (r= epenno)" <repenno@cisco.com>, "behave@ietf.org" <behave@ietf.org>, "Draf= t-Tsou-Behave-Natx4-Log-Reduction@Tools. Ietf. Org" <draft-tsou-behave= -natx4-log-reduction@tools.ietf.org>
Subject: Re: [BEHAVE] Comments on d= raft-sivakumar-behave-nat-logging-05

Dear Senthil, Reinaldo et al,
Draft-sivakumar does describe dynamically assign port range and take l= ogs based on port range, which overlaps much with draft-tsou-behave-natx4-l= og-reduction.

 

http://tools.ietf.org/html/draft-siv= akumar-behave-nat-logging-05#section-4.4.9 describes allocating and retrieving port range, but it is not clear whether one user= can have multiple port range, or only one.

 

Though the focus of this draft is not = how to allocate port range, only mentions what content in the recorded info= rmation. 

This draft currently only supports con= tinuous port range, not non-continuous one.


So I propose these two drafts converge= .


Thank you,
Tina

On Jan 4, 2013, at 6:49 AM, "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com> wrote:



From: Julia Renouard <J.Renouard@F5.com>
Date: Wednesday, January 2, 2013 9:= 05 PM
To: Senthil Sivakumar <ssenthil@cisco.com>, "Reinaldo P= enno (repenno)" <repenno@cisco= .com>, "behave@ietf.org&= quot; <behave@ietf.org>
Subject: RE: Comments on draft-siva= kumar-behave-nat-logging-05

Hi Senthil =96 Nice fa= st turn-around.  So part of my confusion here appears to be derived fr= om your opening sentence in the Abstract and Scope sections:   = =93This document provides the information model to be used for logging the Carrier Grade NAT (CGN) events.=94   So you migh= t want to clarify the scope as well if this is intended to be broader than = CGN.  J  My apologies that I did not review the history= of this draft.  I started with this for review =96 a bit in a vacuum = I admit.

[Senthil] Right, the sentence after = the first one says "The logs are required in many = cases to identify an attacker or a host that was used to launch malicious attacks and/o= r for various other purposes of accounting.", which is not specific to= CGN. But I agree, it might have been misleading. I

 

A follow up thought, i= f this is intended to be for all NAT types, including generic NAT and CGN, = not paying attention to minimizing logging and the bandwidth and data const= raints of the CGN deployments will end up making most CGN devices to only be partially compliant if the recommend= ations laid out here remain a SHOULD or do not take this need into account.=   We will simply have to use it as high-level guidance and take our ow= n path because minimizing logging is a requirement for us.  Even so, I think it will still be useful to id= entify the common use-cases for logging.  This helps better review if = the recommendations you are making achieve those goals or not.

[Senthil] The templates and the framework are generic enough that woul= d be applicable to both. For the log reduction, there are already a couple = of drafts that talks about ways to do that.

 

On the question of the= generic vs specific natEvent enumerations, I actually feel the generic is = more extensible, but yes, I agree =96 broader WG opinions should be sought = and to be honest I have not compared it with other IE=92s for consistency nor looked at IPFIX collector implementa= tions.  My concern is as much from a =93best practice=94 of data hidin= g =96 where events are generic and type is part of data.  This facilit= ates extensibility and future proofing implementations.  The example of the error enumeration is a good one.  As a colle= ctor, I can implement to recognize a generic  =93Translation error=94 = event =96 and I don=92t need to update my software for every new error type= that comes along.  I know I will catch it.  I may not know what type of error but I will know an error occurred.  As for th= e generic NAT events vs. specific type-encoded events, yes I understand the= goal of having the nat type.  You could provide the additional natTyp= e IE in the template but, as you say, that is an additional byte.  However IMHO the value of extensibility outwe= ighs this.  In order to add NAT66, for example, you now need to extend= this yet again.    Not having implemented an IPFIX collecto= r I cannot speak to whether this addition of the NAT type actually resolves any ambiguity that the different templates would not.&nb= sp; (sourceIPv6Address vs. IPv4).    

 

I=92d have to look bac= k in the threads for the feedback on DS-Lite to understand the concerns wrt= this draft, but as an implementer it is something I have to solve.  I= don=92t think it requires any new types.  But I think it would be useful to offer template guidance.  For us, we we= re intending simply to use a sourceIPv6Address IE (consistent with Section = 4 in behave-lsn-requirements).  Optionally we may also include a sourc= eIPv4Address if the customer desired.  Again, I don=92t think it needs its own IE=92s or types, just template guidance a= nd how this will be interpreted commonly by collectors.  Just a though= t=85

 

Thanks again =96 we lo= ok forward to the next round.  I appreciate your work here,=

Julia

 
Thanks
Senthil

 

From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com]
Sent: Wednesday, January 02, 2013 4:14 PM
To: Julia Renouard; Reinaldo Penno (repenno); behave@ietf.org
Subject: Re: Comments on draft-sivakumar-behave-nat-logging-05 =

 

Hi Juli= a,

Thanks = for the comments. Please see inline.

&n= bsp;

From: Julia Renouard <J.Renouard@F5.com>
Date: Wednesday, January 2, 2013 5:28 PM
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>, Senthil Sivakumar <ssenthil@cisco.com>, "behave@ietf.org" <behave@ietf.org>
Subject: Comments on draft-sivakumar-behave-nat-logging-05

&n= bsp;

Hi Reinaldo & Senthil =96

 

Thank you for your work here.  I know this has been through a few = iterations .  I do think this is needed minimally as guidance. &n= bsp; This was the only thing we found, save for section 4 in behave-lsn-requirements that gave guidance on CGN logging.  And yo= ur justification is spot-on.   Now for feedback=85

  

Summary:

First, we are very concerned about the re-enumeration of natEvent value= s in section 4.2.  It is not good practice and is disruptive to implem= enters to re-enumerate published values.  Also the values created here are too specific and make this not-easily extended= .    The only exception I might make here is to change the e= xisting "Pool Exhausted" value to be "Translation Failure&qu= ot; or simply add a new enum for this.  I think generic events are better than specific.  More on this below.

&n= bsp;

[Senthi= l] I assume you mean the IPFIX IANA assigned values for natEvents. You are = right, there is an inconsistency between the two. As you pointed out, the c= reate and delete event is consistent with the IPFIX values, we need to add the poolExhausted value in the draft= or create a new value for it.  We will do it as part of the next rev.=  

 

I would like to see this draft reference and be consistent with draft-i= etf-behave-lsn-requirements-x which does describe, in section 4, logging re= quirements for a CGN.  I think this document needs align with the logging requirements here in the overall goals and co= nstraints.  Namely, the primary goal for NAT logging is to enable the = ability to identify a subscriber - often for legal reasons.  The const= raint that we need to be mindful of is logging resource consumption.  Many CGN features are specifically designed to= minimize log size while still maintaining the ability to identify subscrib= ers - Port block allocation for example.

&n= bsp;

[Senthi= l] This document is not just for CGN logging, it is a generic NAT logging d= ocument that can be used also for satisfying CGN logging requirements. As m= entioned in the scope, the optimization of log events (size, the way you pack the records etc) is not within the s= cope of this document. There are many other documents that provide solution= s for that. The main purpose of this document is to provide a framework and= a template to log NAT events =96 that both the NAT vendors and the collector vendors can use to interoperat= e.

 

CGN logging for the purposes of identifying subscribers and with the go= al of minimizing data consumption, needs to focus on the NAT translations (= bindings) and be as minimalistic as possible.  Flow logging or session logging has a different purpose - statistical, dat= a usage analysis, quality analysis, security, billing=85  There may be= some overlap of use-cases but this document doesn't really speak to them.&= nbsp; It might be interesting to look at typical/traditional NetFlow/IPFIX Flow logging and see how that might be different for a NAT.&= nbsp;  But there are at least 2 different use-cases - if this document= wants to address both, I think it would be useful to distinguish them.&nbs= p; But flow/session logging needs to be discrete because administrators may only choose translation logging for data conser= vation purposes.  It seems to me that your session create/delete event= s fall into this camp, although I=92m interested in your intent here. = Minimally I=92d be interested in a comparison.

&n= bsp;

[Senthi= l] Just to re-iterate, the focus of the draft is generic NAT logging =96 no= t just CGN. The NAT templates defined in the draft is generic enough to cov= er both CGN and non-CGN NAT logging. I am not really sure I understand the gist of the above paragraph, but flow = logging is being used for data retention purposes. Again our intention here= is have a generic logging framework. 

 <= o:p>

 

My high level recommendations:

1.       Don't renumb= er IANA defined enums.  Reasons cited above. 

&n= bsp;

[Senthi= l] Ok. But a lot of what is defined here is what went on to become IANA val= ues, but your point is well taken, we will get rid of inconsistencies.=

&n= bsp;

2.       Keep high le= vel events generic.  This makes them more extensible.  "Crea= te", "Delete" and "Translation Failure" - with mor= e data as additional (optional) IE's.  For example, keeping the "= error" event generic allows collectors to universally identify an error, even as more e= rror types are created. 

[Senthi= l] The problem is if we have a simple create, delete, we wont be able to di= stinguish what kind of an nat this is =96 nat44, nat64 etc. For us to add a= dditional data, that would cause us to have another byte. In this case, we can have a max of 256 types (with 8 bi= ts) and hence make sense to present the information in one shot. I am open = to suggestions here but would like some WG guidance.

&n= bsp;

3.       Be careful a= bout error logging recommendations.  I would set these as MAY with com= ments about limiting how often these are emitted in a pool exhaustion case = so as not to DoS the source or target system. 

[Senthi= l] Agreed. 

&n= bsp;

4.       Consider DSL= ite in your recommendations - what IE's should be used to report a DSLite s= ubscriber? 

&n= bsp;

[Senthi= l] We had DS lite in earlier revision of the draft in -03. But the WG wante= d us to keep it specifically to NAT, so the latest versions got rid of them= .

&n= bsp;

5.       Make the Por= t Block Allocation extensions part of the "Create" and "Dele= te" event templates.

[Senthi= l] Ok.

6.       Call out spe= cifically which IE's are new.  Section 7 is not complete or accurate.&= nbsp; portRange* ID's have been defined.  You also have IE's identifie= d which do not exist and are not called out in section 7.

[Senthi= l] Ok.

7.       Section 4 - = Event based Logging:  "Each of these events SHOULD be logged, unl= ess they are administratively prohibited" - This is a problematic reco= mmendation and is contrary to the need to minimize logging (i.e. logging every session )

[Senthi= l] As I clarified above, minimizing logging is not a goal of this draft.

&n= bsp;

8.       Bring this i= nto alignment with draft-behave-lsn-requirements.   E.g. REQ-12. = Destination addresses SHOULD NOT be logged.  That said, a mapping even= t MAY have a destination address if administrator requires it.  In which case I would recommend only 1 IE - destination= IPxAddress or postNATDestinationIPvxAddress - both seems redundant.

[Senthi= l] I think we can add some text around this, that if the CGN is running, th= en destination address should not be logged.

&n= bsp;

9.       Separate out= session logging from translation logging.  Session logging bloats the= data set and is unnecessary just for identifying subscribers

&n= bsp;

&n= bsp;

10.   Describe the= difference between session logging and BIB(translation) logging and when t= o use them.  IMHO session logging looks a lot more like flow logging.&= nbsp; I'd be interested in a description of the differences and a separate of the two cases.  Perhaps flow loggin= g for NAT's is a separate use-case. 

[Senthi= l] As explained above, for 9 & 10, this is a generic draft.<= /span>

11.   Look at usin= g natPoolName optionally in more events - I think it will be useful, minima= lly for errors

&n= bsp;

[Senthi= l] Ok.

12.   Can we find = an IE to send a "subscriber identity"?  I'm wondering about = #371, "userName" - for a mobile service provider this might actua= lly be an IMSI or IMEI numbers.  This would be optional.

[Senthi= l] I will check, the last time I checked there were a couple of fields that= could be used.  

&n= bsp;

13.   Be mindful o= f the need for data conservation and to minimize logging in your MUST and S= HOULD requirements.  MUST and SHOULD requirements should be minimalist= ic to achieve the base use-case and nothing more.  E.g. look to the data elements identified in behave-lsn-requir= ements.  But ideally it also gives guidance on some typical use-cases = and how to achieve them.

&n= bsp;

[Senthi= l] Minimizing the logging is not the goal of this draft.<= /p>

 

 

One more nit:  = ; [NAT-EVENT-LOG-IANA] - this link does not exist.  You should update = this to be the IANA IPFIX IE registry.

&n= bsp;

[Senthi= l] Ok, thanks.

 

 

Thanks again for this.&n= bsp; I hope this feedback is helpful.  We look forward to the next dra= ft.

 =

[Senthi= l] Thanks for the helpful comments. Will incorporate the relevant ones.

&n= bsp;

Senthil=

&n= bsp;

Happy New Year,

 =

Julia Renouard

--_000_CED6B1CEE368400E99CCB8BD9DAB8554huaweicom_-- From ssenthil@cisco.com Tue Jan 15 08:02:21 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5D421F86B6 for ; Tue, 15 Jan 2013 08:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kx1hxbGs93IL for ; Tue, 15 Jan 2013 08:02:17 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C268321F86A3 for ; Tue, 15 Jan 2013 08:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=65070; q=dns/txt; s=iport; t=1358265737; x=1359475337; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=ME6e1Y+qqbz1qyuzuGiS+F75K7g8+zauSvYxvPk3yL0=; b=bPsD4OEdXc0AIJP33c33U2j4r/CHsTFPnz+3sGbNf0VVmwbAIJ7iN479 HkuQVrVLTiZxdKrFOxbIj2RAu0KD2QRFcu8nXowDQXOJbNvacK0CcgodB U8UhtDqgJlvWnLLvleQ+8hUpTHZQmHMvDWkLbvc9s2adO7HngNyJb9LDo 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIGAAN89VCtJV2a/2dsb2JhbAA7AQmCSLIIAYVqg0gWc4IeAQEBBBoTOhISAQgRAwEBAQsLCwEGORQJCAIEDgUIE4d+DKhzjjeNBgF8glRhA5JZhE+PLYJ1giQ X-IronPort-AV: E=Sophos;i="4.84,473,1355097600"; d="scan'208,217";a="162625436" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 15 Jan 2013 16:02:15 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0FG2FBK006551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jan 2013 16:02:15 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.248]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 15 Jan 2013 10:02:15 -0600 From: "Senthil Sivakumar (ssenthil)" To: Tina TSOU Thread-Topic: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 Thread-Index: AQHN6v78YP2KpbnFuU2gfgvBIZ6BeJhJk9gAgABVO4CAAMUOAA== Date: Tue, 15 Jan 2013 16:02:14 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [64.102.83.131] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D023237BA3Exmbrcdx15ciscoc_" MIME-Version: 1.0 Cc: "Reinaldo Penno \(repenno\)" , "behave@ietf.org" , Julia Renouard , "Draft-Tsou-Behave-Natx4-Log-Reduction@Tools. Ietf. Org" Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 16:02:22 -0000 --_000_CB1B483277FEC94E9B58357040EE5D023237BA3Exmbrcdx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tina, I can add a reference in section 4.4.9 in the next revision. Thanks Senthil From: Tina TSOU > Date: Monday, January 14, 2013 6:16 PM To: Senthil Sivakumar > Cc: "behave@ietf.org" >, "Reinaldo Penno (repenno)" >, Julia Renouard >, = "Draft-Tsou-Behave-Natx4-Log-Reduction@Tools. Ietf. Org" > Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 Dear Senthil, I was talking about the allocating and retrieving port range, not the whole= document. Can section 4.4.9 of draft-Sivakumar reference draft-tsou? Thank you, Tina On Jan 14, 2013, at 3:12 PM, "Senthil Sivakumar (ssenthil)" > wrote: Hi Tina, The focus of the logging draft as it exists is not to reduce the logging, i= t is a framework document that can define templates for logging in a generi= c way. As it says in section 3 "The optimization of logging the NAT events are le= ft to the implementation and are beyond the scope of this document.". We don=92t any overlap between these two documents that requires converging= /merging. Thanks Senthil From: Tina TSOU > Date: Friday, January 4, 2013 11:41 PM To: Senthil Sivakumar > Cc: Julia Renouard >, "Reinaldo= Penno (repenno)" >, "behave@ie= tf.org" >, = "Draft-Tsou-Behave-Natx4-Log-Reduction@Tools. Ietf. Org" > Subject: Re: [BEHAVE] Comments on draft-sivakumar-behave-nat-logging-05 Dear Senthil, Reinaldo et al, Draft-sivakumar does describe dynamically assign port range and take logs b= ased on port range, which overlaps much with draft-tsou-behave-natx4-log-re= duction. http://tools.ietf.org/html/draft-sivakumar-behave-nat-logging-05#section-4.= 4.9 describes allocating and retrieving port range, but it is not clear whe= ther one user can have multiple port range, or only one. Though the focus of this draft is not how to allocate port range, only ment= ions what content in the recorded information. This draft currently only supports continuous port range, not non-continuou= s one. So I propose these two drafts converge. Thank you, Tina On Jan 4, 2013, at 6:49 AM, "Senthil Sivakumar (ssenthil)" > wrote: From: Julia Renouard > Date: Wednesday, January 2, 2013 9:05 PM To: Senthil Sivakumar >, "Rei= naldo Penno (repenno)" >, "beha= ve@ietf.org" > Subject: RE: Comments on draft-sivakumar-behave-nat-logging-05 Hi Senthil =96 Nice fast turn-around. So part of my confusion here appears= to be derived from your opening sentence in the Abstract and Scope section= s: =93This document provides the information model to be used for logging= the Carrier Grade NAT (CGN) events.=94 So you might want to clarify the = scope as well if this is intended to be broader than CGN. :) My apologies= that I did not review the history of this draft. I started with this for = review =96 a bit in a vacuum I admit. [Senthil] Right, the sentence after the first one says "The logs are requir= ed in many cases to identify an attacker or a host that was used to launch = malicious attacks and/or for various other purposes of accounting.", which = is not specific to CGN. But I agree, it might have been misleading. I will = do some wordsmithing to clarify this better. A follow up thought, if this is intended to be for all NAT types, including= generic NAT and CGN, not paying attention to minimizing logging and the ba= ndwidth and data constraints of the CGN deployments will end up making most= CGN devices to only be partially compliant if the recommendations laid out= here remain a SHOULD or do not take this need into account. We will simpl= y have to use it as high-level guidance and take our own path because minim= izing logging is a requirement for us. Even so, I think it will still be u= seful to identify the common use-cases for logging. This helps better revi= ew if the recommendations you are making achieve those goals or not. [Senthil] The templates and the framework are generic enough that would be = applicable to both. For the log reduction, there are already a couple of dr= afts that talks about ways to do that. On the question of the generic vs specific natEvent enumerations, I actuall= y feel the generic is more extensible, but yes, I agree =96 broader WG opin= ions should be sought and to be honest I have not compared it with other IE= =92s for consistency nor looked at IPFIX collector implementations. My con= cern is as much from a =93best practice=94 of data hiding =96 where events = are generic and type is part of data. This facilitates extensibility and f= uture proofing implementations. The example of the error enumeration is a = good one. As a collector, I can implement to recognize a generic =93Trans= lation error=94 event =96 and I don=92t need to update my software for ever= y new error type that comes along. I know I will catch it. I may not know= what type of error but I will know an error occurred. As for the generic = NAT events vs. specific type-encoded events, yes I understand the goal of h= aving the nat type. You could provide the additional natType IE in the tem= plate but, as you say, that is an additional byte. However IMHO the value = of extensibility outweighs this. In order to add NAT66, for example, you n= ow need to extend this yet again. Not having implemented an IPFIX collec= tor I cannot speak to whether this addition of the NAT type actually resolv= es any ambiguity that the different templates would not. (sourceIPv6Addres= s vs. IPv4). I=92d have to look back in the threads for the feedback on DS-Lite to under= stand the concerns wrt this draft, but as an implementer it is something I = have to solve. I don=92t think it requires any new types. But I think it = would be useful to offer template guidance. For us, we were intending simp= ly to use a sourceIPv6Address IE (consistent with Section 4 in behave-lsn-r= equirements). Optionally we may also include a sourceIPv4Address if the cu= stomer desired. Again, I don=92t think it needs its own IE=92s or types, j= ust template guidance and how this will be interpreted commonly by collecto= rs. Just a thought=85 Thanks again =96 we look forward to the next round. I appreciate your work= here, Julia Thanks Senthil From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] Sent: Wednesday, January 02, 2013 4:14 PM To: Julia Renouard; Reinaldo Penno (repenno); behave@ietf.org Subject: Re: Comments on draft-sivakumar-behave-nat-logging-05 Hi Julia, Thanks for the comments. Please see inline. From: Julia Renouard > Date: Wednesday, January 2, 2013 5:28 PM To: "Reinaldo Penno (repenno)" = >, Senthil Sivakumar >, "beha= ve@ietf.org" > Subject: Comments on draft-sivakumar-behave-nat-logging-05 Hi Reinaldo & Senthil =96 Thank you for your work here. I know this has been through a few iteration= s . I do think this is needed minimally as guidance. This was the only t= hing we found, save for section 4 in behave-lsn-requirements that gave guid= ance on CGN logging. And your justification is spot-on. Now for feedback= =85 Summary: First, we are very concerned about the re-enumeration of natEvent values in= section 4.2. It is not good practice and is disruptive to implementers to= re-enumerate published values. Also the values created here are too speci= fic and make this not-easily extended. The only exception I might make h= ere is to change the existing "Pool Exhausted" value to be "Translation Fai= lure" or simply add a new enum for this. I think generic events are better= than specific. More on this below. [Senthil] I assume you mean the IPFIX IANA assigned values for natEvents. Y= ou are right, there is an inconsistency between the two. As you pointed out= , the create and delete event is consistent with the IPFIX values, we need = to add the poolExhausted value in the draft or create a new value for it. = We will do it as part of the next rev. I would like to see this draft reference and be consistent with draft-ietf-= behave-lsn-requirements-x which does describe, in section 4, logging requir= ements for a CGN. I think this document needs align with the logging requi= rements here in the overall goals and constraints. Namely, the primary goa= l for NAT logging is to enable the ability to identify a subscriber - often= for legal reasons. The constraint that we need to be mindful of is loggin= g resource consumption. Many CGN features are specifically designed to min= imize log size while still maintaining the ability to identify subscribers = - Port block allocation for example. [Senthil] This document is not just for CGN logging, it is a generic NAT lo= gging document that can be used also for satisfying CGN logging requirement= s. As mentioned in the scope, the optimization of log events (size, the way= you pack the records etc) is not within the scope of this document. There = are many other documents that provide solutions for that. The main purpose = of this document is to provide a framework and a template to log NAT events= =96 that both the NAT vendors and the collector vendors can use to interop= erate. CGN logging for the purposes of identifying subscribers and with the goal o= f minimizing data consumption, needs to focus on the NAT translations (bind= ings) and be as minimalistic as possible. Flow logging or session logging = has a different purpose - statistical, data usage analysis, quality analysi= s, security, billing=85 There may be some overlap of use-cases but this do= cument doesn't really speak to them. It might be interesting to look at ty= pical/traditional NetFlow/IPFIX Flow logging and see how that might be diff= erent for a NAT. But there are at least 2 different use-cases - if this d= ocument wants to address both, I think it would be useful to distinguish th= em. But flow/session logging needs to be discrete because administrators m= ay only choose translation logging for data conservation purposes. It seem= s to me that your session create/delete events fall into this camp, althoug= h I=92m interested in your intent here. Minimally I=92d be interested in a= comparison. [Senthil] Just to re-iterate, the focus of the draft is generic NAT logging= =96 not just CGN. The NAT templates defined in the draft is generic enough= to cover both CGN and non-CGN NAT logging. I am not really sure I understa= nd the gist of the above paragraph, but flow logging is being used for data= retention purposes. Again our intention here is have a generic logging fra= mework. My high level recommendations: 1. Don't renumber IANA defined enums. Reasons cited above. [Senthil] Ok. But a lot of what is defined here is what went on to become I= ANA values, but your point is well taken, we will get rid of inconsistencie= s. 2. Keep high level events generic. This makes them more extensible. = "Create", "Delete" and "Translation Failure" - with more data as additiona= l (optional) IE's. For example, keeping the "error" event generic allows c= ollectors to universally identify an error, even as more error types are cr= eated. [Senthil] The problem is if we have a simple create, delete, we wont be abl= e to distinguish what kind of an nat this is =96 nat44, nat64 etc. For us t= o add additional data, that would cause us to have another byte. In this ca= se, we can have a max of 256 types (with 8 bits) and hence make sense to pr= esent the information in one shot. I am open to suggestions here but would = like some WG guidance. 3. Be careful about error logging recommendations. I would set these= as MAY with comments about limiting how often these are emitted in a pool = exhaustion case so as not to DoS the source or target system. [Senthil] Agreed. 4. Consider DSLite in your recommendations - what IE's should be used= to report a DSLite subscriber? [Senthil] We had DS lite in earlier revision of the draft in -03. But the W= G wanted us to keep it specifically to NAT, so the latest versions got rid = of them. 5. Make the Port Block Allocation extensions part of the "Create" and= "Delete" event templates. [Senthil] Ok. 6. Call out specifically which IE's are new. Section 7 is not comple= te or accurate. portRange* ID's have been defined. You also have IE's ide= ntified which do not exist and are not called out in section 7. [Senthil] Ok. 7. Section 4 - Event based Logging: "Each of these events SHOULD be = logged, unless they are administratively prohibited" - This is a problemati= c recommendation and is contrary to the need to minimize logging (i.e. logg= ing every session ) [Senthil] As I clarified above, minimizing logging is not a goal of this dr= aft. 8. Bring this into alignment with draft-behave-lsn-requirements. E.= g. REQ-12. Destination addresses SHOULD NOT be logged. That said, a mappin= g event MAY have a destination address if administrator requires it. In wh= ich case I would recommend only 1 IE - destinationIPxAddress or postNATDest= inationIPvxAddress - both seems redundant. [Senthil] I think we can add some text around this, that if the CGN is runn= ing, then destination address should not be logged. 9. Separate out session logging from translation logging. Session lo= gging bloats the data set and is unnecessary just for identifying subscribe= rs 10. Describe the difference between session logging and BIB(translation) = logging and when to use them. IMHO session logging looks a lot more like f= low logging. I'd be interested in a description of the differences and a s= eparate of the two cases. Perhaps flow logging for NAT's is a separate use= -case. [Senthil] As explained above, for 9 & 10, this is a generic draft. 11. Look at using natPoolName optionally in more events - I think it will= be useful, minimally for errors [Senthil] Ok. 12. Can we find an IE to send a "subscriber identity"? I'm wondering abo= ut #371, "userName" - for a mobile service provider this might actually be = an IMSI or IMEI numbers. This would be optional. [Senthil] I will check, the last time I checked there were a couple of fiel= ds that could be used. 13. Be mindful of the need for data conservation and to minimize logging = in your MUST and SHOULD requirements. MUST and SHOULD requirements should = be minimalistic to achieve the base use-case and nothing more. E.g. look t= o the data elements identified in behave-lsn-requirements. But ideally it = also gives guidance on some typical use-cases and how to achieve them. [Senthil] Minimizing the logging is not the goal of this draft. One more nit: [NAT-EVENT-LOG-IANA] - this link does not exist. You shoul= d update this to be the IANA IPFIX IE registry. [Senthil] Ok, thanks. Thanks again for this. I hope this feedback is helpful. We look forward t= o the next draft. [Senthil] Thanks for the helpful comments. Will incorporate the relevant on= es. Senthil Happy New Year, Julia Renouard --_000_CB1B483277FEC94E9B58357040EE5D023237BA3Exmbrcdx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <107A15762A26BB4D99EC62F014220C6A@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Tina,
I can add a reference in section 4.4.9 in the next revision. 

Thanks
Senthil

From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
Date: Monday, January 14, 2013 6:16= PM
To: Senthil Sivakumar <ssenthil@cisco.com>
Cc: "behave@ietf.org" <= behave@ietf.org>, "Reinaldo Penno (repenno)" <repenno@cisco.com>, Julia Renouard <= ;J.Renouard@F5.com>, "Draft-Tsou-Behave-Natx4-Log-Reduction@Tools. Ietf. Org" <draft-= tsou-behave-natx4-log-reduction@tools.ietf.org>
Subject: Re: [BEHAVE] Comments on d= raft-sivakumar-behave-nat-logging-05

Dear Senthil,
I was talking about the allocating and retrieving port range, not the whole document.
Can section 4.4.9 of draft-Sivakumar reference draft-tsou?

Thank you,
Tina

On Jan 14, 2013, at 3:12 PM, "Senthil Sivakumar (ssenthil)" <<= a href=3D"mailto:ssenthil@cisco.com">ssenthil@cisco.com> wrote:

Hi Tina,
The focus of the logging draft as it exists is not to reduce the logging, i= t is a framework document that can define templates for logging in a generi= c way.
As it says in  section 3 "The optimization of logging the NAT events are left to the implementation and are beyond the scope of = this document.".
We don=92t any overlap between these two documents that requires conve= rging/merging.

Thanks
Senthil

From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
Date: Friday, January 4, 2013 11:41= PM
To: Senthil Sivakumar <ssenthil@cisco.com>
Cc: Julia Renouard <J.Renouard@F5.com>, "Reinaldo Penno (r= epenno)" <repenno@cisco.com>, "behave@ietf.org" <behave@ietf.org>, "Draf= t-Tsou-Behave-Natx4-Log-Reduction@Tools. Ietf. Org" <draft-tsou-behave= -natx4-log-reduction@tools.ietf.org>
Subject: Re: [BEHAVE] Comments on d= raft-sivakumar-behave-nat-logging-05

Dear Senthil, Reinaldo et al,
Draft-sivakumar does describe dynamically assign port range and take l= ogs based on port range, which overlaps much with draft-tsou-behave-natx4-l= og-reduction.

 

http://tools.ietf.org/html/draft-siv= akumar-behave-nat-logging-05#section-4.4.9 describes allocating and retrieving port range, but it is not clear whether one user= can have multiple port range, or only one.

 

Though the focus of this draft is not = how to allocate port range, only mentions what content in the recorded info= rmation. 

This draft currently only supports con= tinuous port range, not non-continuous one.


So I propose these two drafts converge= .


Thank you,
Tina

On Jan 4, 2013, at 6:49 AM, "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com> wrote:



From: Julia Renouard <J.Renouard@F5.com>
Date: Wednesday, January 2, 2013 9:= 05 PM
To: Senthil Sivakumar <ssenthil@cisco.com>, "Reinaldo P= enno (repenno)" <repenno@cisco= .com>, "behave@ietf.org&= quot; <behave@ietf.org>
Subject: RE: Comments on draft-siva= kumar-behave-nat-logging-05

Hi Senthil =96 Nice fa= st turn-around.  So part of my confusion here appears to be derived fr= om your opening sentence in the Abstract and Scope sections:   = =93This document provides the information model to be used for logging the Carrier Grade NAT (CGN) events.=94   So you migh= t want to clarify the scope as well if this is intended to be broader than = CGN.  J  My apologies that I did not review the history= of this draft.  I started with this for review =96 a bit in a vacuum = I admit.

[Senthil] Right, the sentence after = the first one says "The logs are required in many = cases to identify an attacker or a host that was used to launch malicious attacks and/o= r for various other purposes of accounting.", which is not specific to= CGN. But I agree, it might have been misleading. I

 

A follow up thought, i= f this is intended to be for all NAT types, including generic NAT and CGN, = not paying attention to minimizing logging and the bandwidth and data const= raints of the CGN deployments will end up making most CGN devices to only be partially compliant if the recommend= ations laid out here remain a SHOULD or do not take this need into account.=   We will simply have to use it as high-level guidance and take our ow= n path because minimizing logging is a requirement for us.  Even so, I think it will still be useful to id= entify the common use-cases for logging.  This helps better review if = the recommendations you are making achieve those goals or not.

[Senthil] The templates and the framework are generic enough that woul= d be applicable to both. For the log reduction, there are already a couple = of drafts that talks about ways to do that.

 

On the question of the= generic vs specific natEvent enumerations, I actually feel the generic is = more extensible, but yes, I agree =96 broader WG opinions should be sought = and to be honest I have not compared it with other IE=92s for consistency nor looked at IPFIX collector implementa= tions.  My concern is as much from a =93best practice=94 of data hidin= g =96 where events are generic and type is part of data.  This facilit= ates extensibility and future proofing implementations.  The example of the error enumeration is a good one.  As a colle= ctor, I can implement to recognize a generic  =93Translation error=94 = event =96 and I don=92t need to update my software for every new error type= that comes along.  I know I will catch it.  I may not know what type of error but I will know an error occurred.  As for th= e generic NAT events vs. specific type-encoded events, yes I understand the= goal of having the nat type.  You could provide the additional natTyp= e IE in the template but, as you say, that is an additional byte.  However IMHO the value of extensibility outwe= ighs this.  In order to add NAT66, for example, you now need to extend= this yet again.    Not having implemented an IPFIX collecto= r I cannot speak to whether this addition of the NAT type actually resolves any ambiguity that the different templates would not.&nb= sp; (sourceIPv6Address vs. IPv4).    

 

I=92d have to look bac= k in the threads for the feedback on DS-Lite to understand the concerns wrt= this draft, but as an implementer it is something I have to solve.  I= don=92t think it requires any new types.  But I think it would be useful to offer template guidance.  For us, we we= re intending simply to use a sourceIPv6Address IE (consistent with Section = 4 in behave-lsn-requirements).  Optionally we may also include a sourc= eIPv4Address if the customer desired.  Again, I don=92t think it needs its own IE=92s or types, just template guidance a= nd how this will be interpreted commonly by collectors.  Just a though= t=85

 

Thanks again =96 we lo= ok forward to the next round.  I appreciate your work here,=

Julia

 
Thanks
Senthil

 

From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com]
Sent: Wednesday, January 02, 2013 4:14 PM
To: Julia Renouard; Reinaldo Penno (repenno); behave@ietf.org
Subject: Re: Comments on draft-sivakumar-behave-nat-logging-05 =

 

Hi Juli= a,

Thanks = for the comments. Please see inline.

&n= bsp;

From: Julia Renouard <J.Renouard@F5.com>
Date: Wednesday, January 2, 2013 5:28 PM
To: "Reinaldo Penno (repenno)" <repenno@cisco.com>, Senthil Sivakumar <ssenthil@cisco.com>, "behave@ietf.org" <behave@ietf.org>
Subject: Comments on draft-sivakumar-behave-nat-logging-05

&n= bsp;

Hi Reinaldo & Senthil =96

 

Thank you for your work here.  I know this has been through a few = iterations .  I do think this is needed minimally as guidance. &n= bsp; This was the only thing we found, save for section 4 in behave-lsn-requirements that gave guidance on CGN logging.  And yo= ur justification is spot-on.   Now for feedback=85

  

Summary:

First, we are very concerned about the re-enumeration of natEvent value= s in section 4.2.  It is not good practice and is disruptive to implem= enters to re-enumerate published values.  Also the values created here are too specific and make this not-easily extended= .    The only exception I might make here is to change the e= xisting "Pool Exhausted" value to be "Translation Failure&qu= ot; or simply add a new enum for this.  I think generic events are better than specific.  More on this below.

&n= bsp;

[Senthi= l] I assume you mean the IPFIX IANA assigned values for natEvents. You are = right, there is an inconsistency between the two. As you pointed out, the c= reate and delete event is consistent with the IPFIX values, we need to add the poolExhausted value in the draft= or create a new value for it.  We will do it as part of the next rev.=  

 

I would like to see this draft reference and be consistent with draft-i= etf-behave-lsn-requirements-x which does describe, in section 4, logging re= quirements for a CGN.  I think this document needs align with the logging requirements here in the overall goals and co= nstraints.  Namely, the primary goal for NAT logging is to enable the = ability to identify a subscriber - often for legal reasons.  The const= raint that we need to be mindful of is logging resource consumption.  Many CGN features are specifically designed to= minimize log size while still maintaining the ability to identify subscrib= ers - Port block allocation for example.

&n= bsp;

[Senthi= l] This document is not just for CGN logging, it is a generic NAT logging d= ocument that can be used also for satisfying CGN logging requirements. As m= entioned in the scope, the optimization of log events (size, the way you pack the records etc) is not within the s= cope of this document. There are many other documents that provide solution= s for that. The main purpose of this document is to provide a framework and= a template to log NAT events =96 that both the NAT vendors and the collector vendors can use to interoperat= e.

 

CGN logging for the purposes of identifying subscribers and with the go= al of minimizing data consumption, needs to focus on the NAT translations (= bindings) and be as minimalistic as possible.  Flow logging or session logging has a different purpose - statistical, dat= a usage analysis, quality analysis, security, billing=85  There may be= some overlap of use-cases but this document doesn't really speak to them.&= nbsp; It might be interesting to look at typical/traditional NetFlow/IPFIX Flow logging and see how that might be different for a NAT.&= nbsp;  But there are at least 2 different use-cases - if this document= wants to address both, I think it would be useful to distinguish them.&nbs= p; But flow/session logging needs to be discrete because administrators may only choose translation logging for data conser= vation purposes.  It seems to me that your session create/delete event= s fall into this camp, although I=92m interested in your intent here. = Minimally I=92d be interested in a comparison.

&n= bsp;

[Senthi= l] Just to re-iterate, the focus of the draft is generic NAT logging =96 no= t just CGN. The NAT templates defined in the draft is generic enough to cov= er both CGN and non-CGN NAT logging. I am not really sure I understand the gist of the above paragraph, but flow = logging is being used for data retention purposes. Again our intention here= is have a generic logging framework. 

 <= o:p>

 

My high level recommendations:

1.       Don't renumb= er IANA defined enums.  Reasons cited above. 

&n= bsp;

[Senthi= l] Ok. But a lot of what is defined here is what went on to become IANA val= ues, but your point is well taken, we will get rid of inconsistencies.=

&n= bsp;

2.       Keep high le= vel events generic.  This makes them more extensible.  "Crea= te", "Delete" and "Translation Failure" - with mor= e data as additional (optional) IE's.  For example, keeping the "= error" event generic allows collectors to universally identify an error, even as more e= rror types are created. 

[Senthi= l] The problem is if we have a simple create, delete, we wont be able to di= stinguish what kind of an nat this is =96 nat44, nat64 etc. For us to add a= dditional data, that would cause us to have another byte. In this case, we can have a max of 256 types (with 8 bi= ts) and hence make sense to present the information in one shot. I am open = to suggestions here but would like some WG guidance.

&n= bsp;

3.       Be careful a= bout error logging recommendations.  I would set these as MAY with com= ments about limiting how often these are emitted in a pool exhaustion case = so as not to DoS the source or target system. 

[Senthi= l] Agreed. 

&n= bsp;

4.       Consider DSL= ite in your recommendations - what IE's should be used to report a DSLite s= ubscriber? 

&n= bsp;

[Senthi= l] We had DS lite in earlier revision of the draft in -03. But the WG wante= d us to keep it specifically to NAT, so the latest versions got rid of them= .

&n= bsp;

5.       Make the Por= t Block Allocation extensions part of the "Create" and "Dele= te" event templates.

[Senthi= l] Ok.

6.       Call out spe= cifically which IE's are new.  Section 7 is not complete or accurate.&= nbsp; portRange* ID's have been defined.  You also have IE's identifie= d which do not exist and are not called out in section 7.

[Senthi= l] Ok.

7.       Section 4 - = Event based Logging:  "Each of these events SHOULD be logged, unl= ess they are administratively prohibited" - This is a problematic reco= mmendation and is contrary to the need to minimize logging (i.e. logging every session )

[Senthi= l] As I clarified above, minimizing logging is not a goal of this draft.

&n= bsp;

8.       Bring this i= nto alignment with draft-behave-lsn-requirements.   E.g. REQ-12. = Destination addresses SHOULD NOT be logged.  That said, a mapping even= t MAY have a destination address if administrator requires it.  In which case I would recommend only 1 IE - destination= IPxAddress or postNATDestinationIPvxAddress - both seems redundant.

[Senthi= l] I think we can add some text around this, that if the CGN is running, th= en destination address should not be logged.

&n= bsp;

9.       Separate out= session logging from translation logging.  Session logging bloats the= data set and is unnecessary just for identifying subscribers

&n= bsp;

&n= bsp;

10.   Describe the= difference between session logging and BIB(translation) logging and when t= o use them.  IMHO session logging looks a lot more like flow logging.&= nbsp; I'd be interested in a description of the differences and a separate of the two cases.  Perhaps flow loggin= g for NAT's is a separate use-case. 

[Senthi= l] As explained above, for 9 & 10, this is a generic draft.<= /span>

11.   Look at usin= g natPoolName optionally in more events - I think it will be useful, minima= lly for errors

&n= bsp;

[Senthi= l] Ok.

12.   Can we find = an IE to send a "subscriber identity"?  I'm wondering about = #371, "userName" - for a mobile service provider this might actua= lly be an IMSI or IMEI numbers.  This would be optional.

[Senthi= l] I will check, the last time I checked there were a couple of fields that= could be used.  

&n= bsp;

13.   Be mindful o= f the need for data conservation and to minimize logging in your MUST and S= HOULD requirements.  MUST and SHOULD requirements should be minimalist= ic to achieve the base use-case and nothing more.  E.g. look to the data elements identified in behave-lsn-requir= ements.  But ideally it also gives guidance on some typical use-cases = and how to achieve them.

&n= bsp;

[Senthi= l] Minimizing the logging is not the goal of this draft.<= /p>

 

 

One more nit:  = ; [NAT-EVENT-LOG-IANA] - this link does not exist.  You should update = this to be the IANA IPFIX IE registry.

&n= bsp;

[Senthi= l] Ok, thanks.

 

 

Thanks again for this.&n= bsp; I hope this feedback is helpful.  We look forward to the next dra= ft.

 =

[Senthi= l] Thanks for the helpful comments. Will incorporate the relevant ones.

&n= bsp;

Senthil=

&n= bsp;

Happy New Year,

 =

Julia Renouard

 --_000_CB1B483277FEC94E9B58357040EE5D023237BA3Exmbrcdx15ciscoc_-- From dthaler@microsoft.com Fri Jan 18 15:48:00 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7151521F84B6 for ; Fri, 18 Jan 2013 15:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yegZVeBCoKMd for ; Fri, 18 Jan 2013 15:47:59 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.32]) by ietfa.amsl.com (Postfix) with ESMTP id BFD1E21F8495 for ; Fri, 18 Jan 2013 15:47:56 -0800 (PST) Received: from BL2FFO11FD004.protection.gbl (10.173.161.203) by BL2FFO11HUB038.protection.gbl (10.173.160.242) with Microsoft SMTP Server (TLS) id 15.0.596.13; Fri, 18 Jan 2013 23:47:54 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD004.mail.protection.outlook.com (10.173.160.104) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Fri, 18 Jan 2013 23:47:54 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 18 Jan 2013 23:47:28 +0000 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.35]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0328.011; Fri, 18 Jan 2013 15:47:28 -0800 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: NAT logging drafts Thread-Index: Ac311HcfR1GOEr0gTyyHDptnpCHF+g== Date: Fri, 18 Jan 2013 23:47:27 +0000 Message-ID: <341064315C6D0D498193B256F238CF972E8CBD@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_341064315C6D0D498193B256F238CF972E8CBDTK5EX14MBXW603win_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(47736001)(44976002)(46102001)(59766001)(56816002)(74502001)(31966008)(4396001)(15202345001)(53806001)(77982001)(54356001)(56776001)(47446002)(51856001)(5343655001)(50986001)(74662001)(16406001)(16236675001)(49866001)(54316002)(55846006)(79102001)(512954001)(33656001)(76482001)(47976001)(5343635001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB038; H:TK5EX14HUBC106.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0730093765 Subject: [BEHAVE] NAT logging drafts X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 23:48:00 -0000 --_000_341064315C6D0D498193B256F238CF972E8CBDTK5EX14MBXW603win_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have two individual drafts under discussion: * draft-sivakumar-behave-nat-logging (using IPFIX) * draft-zhou-behave-syslog-nat-logging (using SYSLOG) Based on the WG discussion to date, we as chairs are fine adopting both documents as WG documents (so the next rev can be draft-ietf-behave-...-00) with the following constraints... The two documents appear to target the same scenario but expose different information. Our expectation is that the two mechanisms will either be consistent (as much as allowed by the underlying protocols) or else they will motivate why their scenarios are inherently different. This is a requirement before going to WGLC. At next IETF, we would like to see a presentation on the differences in the data/events exposed by the two drafts, where the authors of both drafts agree on what the differences are. We can then use the meeting to discuss what the right way to address each difference is. -Dave and Dan --_000_341064315C6D0D498193B256F238CF972E8CBDTK5EX14MBXW603win_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have two individual drafts under discussion:=

* draft-sivakumar-behave-nat-logging (using IPFIX)

* draft-zhou-behave-syslog-nat-logging (using SYSLOG= )

 

Based on the WG discussion to date, we as chairs are= fine adopting

both documents as WG documents (so the next rev can = be

draft-ietf-behave-…-00) with the following con= straints…

 

The two documents appear to target the same scenario= but expose

different information.   Our expectation i= s that the two mechanisms

will either be consistent (as much as allowed by the= underlying protocols)

or else they will motivate why their scenarios are i= nherently different.

This is a requirement before going to WGLC.

 

At next IETF, we would like to see a presentation on= the differences

in the data/events exposed by the two drafts, where = the authors of both

drafts agree on what the differences are.  = ; We can then use the meeting

to discuss what the right way to address each differ= ence is.

 

-Dave and Dan

 

 

 

--_000_341064315C6D0D498193B256F238CF972E8CBDTK5EX14MBXW603win_-- From ssenthil@cisco.com Sat Jan 19 07:22:29 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0747621F8487 for ; Sat, 19 Jan 2013 07:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-LQQYMSdP5O for ; Sat, 19 Jan 2013 07:22:28 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8C40121F8475 for ; Sat, 19 Jan 2013 07:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8536; q=dns/txt; s=iport; t=1358608947; x=1359818547; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=I4JOofTQ/YZxXiwfUFCkYGV9G4JL9gUjk+cPDdlscXQ=; b=Q2/2BY9OiIpJnKyrCGRSEE1Yg3I9j//Oo8kSSmou8B075otNSbAa91x4 /dYbdRs6uXVmoJnPzM8FgOQ8sQx+DA+crGEGN95GudJ+eZXr2zyTLvztZ klO4ho+DX7vXH/anbiHTF9Yx60PGAYYqvklG4AGoFuAshMKm9IHqYgDUB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMe4+lCtJV2Y/2dsb2JhbABEgki7dxZzgh4BAQEELV4BCA4DAwECCx05FAkIAQEEARIIiBG8ApBYYQOmVYJ1giQ X-IronPort-AV: E=Sophos;i="4.84,498,1355097600"; d="scan'208,217";a="161898187" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jan 2013 15:22:27 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0JFMQIu005271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Jan 2013 15:22:27 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.248]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Sat, 19 Jan 2013 09:22:26 -0600 From: "Senthil Sivakumar (ssenthil)" To: Dave Thaler , "behave@ietf.org" Thread-Topic: [BEHAVE] NAT logging drafts Thread-Index: Ac311HcfR1GOEr0gTyyHDptnpCHF+gAjLJCA Date: Sat, 19 Jan 2013 15:22:26 +0000 Message-ID: In-Reply-To: <341064315C6D0D498193B256F238CF972E8CBD@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.117.198.136] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D0232384FCFxmbrcdx15ciscoc_" MIME-Version: 1.0 Subject: Re: [BEHAVE] NAT logging drafts X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 15:22:29 -0000 --_000_CB1B483277FEC94E9B58357040EE5D0232384FCFxmbrcdx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Dave Thaler > Date: Friday, January 18, 2013 6:47 PM To: "behave@ietf.org" > Subject: [BEHAVE] NAT logging drafts We have two individual drafts under discussion: * draft-sivakumar-behave-nat-logging (using IPFIX) * draft-zhou-behave-syslog-nat-logging (using SYSLOG) Based on the WG discussion to date, we as chairs are fine adopting both documents as WG documents (so the next rev can be draft-ietf-behave-=85-00) with the following constraints=85 The two documents appear to target the same scenario but expose different information. Our expectation is that the two mechanisms will either be consistent (as much as allowed by the underlying protocols) or else they will motivate why their scenarios are inherently different. This is a requirement before going to WGLC. [Senthil] One of the key differences is that draft-sivakumar is broader in = scope including both CGN and non-CGN logging. Even with CGN logging, the destination address/por= ts may be a requirement In some deployments that the draft-zhou does not seem to address. The other= events like address exhaustion and other resource exhaustion is not addressed in draft-zhou. At next IETF, we would like to see a presentation on the differences in the data/events exposed by the two drafts, where the authors of both drafts agree on what the differences are. We can then use the meeting to discuss what the right way to address each difference is. [Senthil] Ok. Thanks Senthil -Dave and Dan --_000_CB1B483277FEC94E9B58357040EE5D0232384FCFxmbrcdx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Dave Thaler <dthaler@microsoft.com>
Date: Friday, January 18, 2013 6:47= PM
To: "behave@ietf.org" <= behave@ietf.org>
Subject: [BEHAVE] NAT logging draft= s

We have two individual drafts under discussion:=

* draft-sivakumar-behave-nat-logging (using IPFIX)

* draft-zhou-behave-syslog-nat-logging (using SYSLOG= )

 

Based on the WG discussion to date, we as chairs are= fine adopting

both documents as WG documents (so the next rev can = be

draft-ietf-behave-=85-00) with the following constra= ints=85

 

The two documents appear to target the same scenario= but expose

different information.   Our expectation i= s that the two mechanisms

will either be consistent (as much as allowed by the= underlying protocols)

or else they will motivate why their scenarios are i= nherently different.

This is a requirement before going to WGLC.

[Senthil] One of the key differences is that draft-sivakumar is broade= r in scope including both 
CGN and non-CGN logging. Even with CGN logging, the destination addres= s/ports may be a requirement 
In some deployments that the draft-zhou does not seem to address. The = other events like address
exhaustion and other resource exhaustion is not addressed in draft-zho= u.

 

At next IETF, we would like to see a presentation on= the differences

in the data/events exposed by the two drafts, where = the authors of both

drafts agree on what the differences are.  = ; We can then use the meeting

to discuss what the right way to address each differ= ence is.

[Senthil] Ok.

Thanks
Senthil

 

-Dave and Dan

 

 

 

 --_000_CB1B483277FEC94E9B58357040EE5D0232384FCFxmbrcdx15ciscoc_-- From cathy.zhou@huawei.com Sun Jan 20 22:01:53 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9F821F8820 for ; Sun, 20 Jan 2013 22:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEtmFoM45gRQ for ; Sun, 20 Jan 2013 22:01:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7298E21F86FF for ; Sun, 20 Jan 2013 22:01:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOY63086; Mon, 21 Jan 2013 06:01:47 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 21 Jan 2013 06:01:39 +0000 Received: from SZXEML453-HUB.china.huawei.com (10.82.67.196) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 21 Jan 2013 06:01:45 +0000 Received: from SZXEML527-MBX.china.huawei.com ([169.254.3.141]) by SZXEML453-HUB.china.huawei.com ([10.82.67.196]) with mapi id 14.01.0323.007; Mon, 21 Jan 2013 14:01:38 +0800 From: "Zhouqian (Cathy)" To: "Senthil Sivakumar (ssenthil)" , Dave Thaler , "behave@ietf.org" Thread-Topic: [BEHAVE] NAT logging drafts Thread-Index: Ac311HcfR1GOEr0gTyyHDptnpCHF+gAjLJCAAE6iD2A= Date: Mon, 21 Jan 2013 06:01:38 +0000 Message-ID: References: <341064315C6D0D498193B256F238CF972E8CBD@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.118] Content-Type: multipart/alternative; boundary="_000_A6A061BEE5DDC94A9692D9D81AF776DF2D562F6Aszxeml527mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [BEHAVE] NAT logging drafts X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 06:01:53 -0000 --_000_A6A061BEE5DDC94A9692D9D81AF776DF2D562F6Aszxeml527mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Senthil Sivakumar (ssenthil) Sent: Saturday, January 19, 2013 11:22 PM To: Dave Thaler; behave@ietf.org Subject: Re: [BEHAVE] NAT logging drafts From: Dave Thaler > Date: Friday, January 18, 2013 6:47 PM To: "behave@ietf.org" > Subject: [BEHAVE] NAT logging drafts We have two individual drafts under discussion: * draft-sivakumar-behave-nat-logging (using IPFIX) * draft-zhou-behave-syslog-nat-logging (using SYSLOG) Based on the WG discussion to date, we as chairs are fine adopting both documents as WG documents (so the next rev can be draft-ietf-behave-...-00) with the following constraints... The two documents appear to target the same scenario but expose different information. Our expectation is that the two mechanisms will either be consistent (as much as allowed by the underlying protocols) or else they will motivate why their scenarios are inherently different. This is a requirement before going to WGLC. [Senthil] One of the key differences is that draft-sivakumar is broader in = scope including both CGN and non-CGN logging. Even with CGN logging, the destination address/por= ts may be a requirement In some deployments that the draft-zhou does not seem to address. The other= events like address exhaustion and other resource exhaustion is not addressed in draft-zhou. [Cathy] The essential difference between the two drafts is just the protoco= l used: IPFIX vs. SYSLOG. In doing the SYSLOG draft, we took a conservative a= pproach because we had been warned in prior discussion that every operator had its = own requirements. We are quite happy to add any additional information that the Working Group sees as desirable. At next IETF, we would like to see a presentation on the differences in the data/events exposed by the two drafts, where the authors of both drafts agree on what the differences are. We can then use the meeting to discuss what the right way to address each difference is. [Senthil] Ok. [Cathy]Ok. Best Regards, Cathy Thanks Senthil -Dave and Dan --_000_A6A061BEE5DDC94A9692D9D81AF776DF2D562F6Aszxeml527mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.o= rg] On Behalf Of Senthil Sivakumar (ssenthil)
Sent: Saturday, January 19, 2013 11:22 PM
To: Dave Thaler; behave@ietf.org
Subject: Re: [BEHAVE] NAT logging drafts

 

 

 

From: = Dave Thaler <dthaler@microsoft.com>
Date: Friday, January 18, 2013 6:47 PM
To: "behave@ietf.org&quo= t; <behave@ietf.org>
Subject: [BEHAVE] NAT logging drafts

 

We have t= wo individual drafts under discussion:

* draft-s= ivakumar-behave-nat-logging (using IPFIX)

* draft-z= hou-behave-syslog-nat-logging (using SYSLOG)

 

Based on = the WG discussion to date, we as chairs are fine adopting=

both docu= ments as WG documents (so the next rev can be

draft-iet= f-behave-…-00) with the following constraints…

 

The two d= ocuments appear to target the same scenario but expose

different= information.   Our expectation is that the two mechanisms

will eith= er be consistent (as much as allowed by the underlying protocols)

or else t= hey will motivate why their scenarios are inherently different.

This is a= requirement before going to WGLC.

 

[Senthil] One of the key differences is that draft-sivakumar is broa= der in scope including both 

CGN and non-CGN logging. Even with CGN logging, the destination addr= ess/ports may be a requirement 

In some deployments that the draft-zhou does not seem to address. Th= e other events like address

exhaustion and other resource exhaustion is not addressed in draft-z= hou.=

 

[Cat= hy] The essential differ= ence between the two drafts is just the protocol

used= : IPFIX vs. SYSLOG. In doing the SYSLOG draft, we took a conservative appro= ach

beca= use we had been warned in prior discussion that every operator had its own

requ= irements. We are quite happy to add any additional information that

the = Working Group sees as desirable.

 

 

At next I= ETF, we would like to see a presentation on the differences

in the da= ta/events exposed by the two drafts, where the authors of both

drafts ag= ree on what the differences are.   We can then use the meeting

to discus= s what the right way to address each difference is.

 

[Senthil] Ok.

[Cat= hy]Ok.

 

Best= Regards,

Cath= y

 

 

Thanks

Senthil

 

-Dave and= Dan

 

 

 

--_000_A6A061BEE5DDC94A9692D9D81AF776DF2D562F6Aszxeml527mbxchi_-- From iesg-secretary@ietf.org Tue Jan 22 07:42:02 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF2721F8A4A; Tue, 22 Jan 2013 07:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.273 X-Spam-Level: X-Spam-Status: No, score=-102.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Vs-1C7sB3FD; Tue, 22 Jan 2013 07:42:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9307321F8A3E; Tue, 22 Jan 2013 07:42:01 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130122154201.10413.33584.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2013 07:42:01 -0800 Cc: behave@ietf.org Subject: [BEHAVE] Last Call: (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis) to Proposed Standard X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 15:42:02 -0000 The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1795/ From wwwrun@rfc-editor.org Tue Jan 22 19:27:18 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C8421F880B for ; Tue, 22 Jan 2013 19:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.333 X-Spam-Level: X-Spam-Status: No, score=-101.333 tagged_above=-999 required=5 tests=[AWL=1.267, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8KrzohPkGZM for ; Tue, 22 Jan 2013 19:27:17 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1E521F851E for ; Tue, 22 Jan 2013 19:27:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6B42772E039; Tue, 22 Jan 2013 19:16:05 -0800 (PST) To: simon.perreault@viagenie.ca, jdrosen@jdrosen.net, wes@mti-systems.com, martin.stiemerling@neclab.eu, dwing@cisco.com, dthaler@microsoft.com From: RFC Errata System Message-Id: <20130123031605.6B42772E039@rfc-editor.org> Date: Tue, 22 Jan 2013 19:16:05 -0800 (PST) Cc: behave@ietf.org, shakeeb@engr.eyeball.com, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Technical Errata Reported] RFC6062 (3467) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 03:27:18 -0000 The following errata report has been submitted for RFC6062, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6062&eid=3467 -------------------------------------- Type: Technical Reported by: Nazmus Shakeeb Section: 5.2. Original Text ------------- the server MUST initiate an outgoing TCP connection. The local endpoint is the relayed transport address associated with the allocation. Corrected Text -------------- the server MUST initiate an outgoing TCP connection. This connection MUST NOT be made using the relayed transport address associated with the allocation. Notes ----- if you send connect request using the allocated port then port the will not be in listen mode and this will prevent incoming tcp connection on this port. this will cause major problem while doing ice check. The effect is so bad that it may cause 97% call failure while using turn tcp behind nat. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6062 (draft-ietf-behave-turn-tcp-07) -------------------------------------- Title : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations Publication Date : November 2010 Author(s) : S. Perreault, Ed., J. Rosenberg Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From simon.perreault@viagenie.ca Wed Jan 23 03:23:56 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E891921F8920 for ; Wed, 23 Jan 2013 03:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usIJ5gGHOG1B for ; Wed, 23 Jan 2013 03:23:56 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6072521F8881 for ; Wed, 23 Jan 2013 03:23:56 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 777014042F; Wed, 23 Jan 2013 06:23:54 -0500 (EST) Message-ID: <50FFC87A.3010004@viagenie.ca> Date: Wed, 23 Jan 2013 12:24:42 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: RFC Errata System References: <20130123031605.6B42772E039@rfc-editor.org> In-Reply-To: <20130123031605.6B42772E039@rfc-editor.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org, jdrosen@jdrosen.net, dthaler@microsoft.com, wes@mti-systems.com, dwing@cisco.com, martin.stiemerling@neclab.eu, shakeeb@engr.eyeball.com Subject: Re: [BEHAVE] [Technical Errata Reported] RFC6062 (3467) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 11:23:57 -0000 Interesting... It is instructive to go back to a very old thread: http://www.ietf.org/mail-archive/web/behave/current/msg05542.html Here's the relevant part: > It it possible to create multiple sockets with SO_REUSEADDR that are > all bound to the same IP address and port. The TURN TCP protocol > can hide this and simply allow multiple incoming or outgoing > connections, simultaneously or sequentially. So, is it actually possible to do that or not? On Linux at least it looks like it is not possible. From socket(7): SO_REUSEADDR Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses. For AF_INET sockets this means that a socket may bind, *except when there is an active listening socket bound to the address*. When the listening socket is bound to INADDR_ANY with a specific port then it is not possi†ble to bind to this port for any local address. Argument is an integer boolean flag Simon Le 2013-01-23 04:16, RFC Errata System a écrit : > The following errata report has been submitted for RFC6062, > "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6062&eid=3467 > > -------------------------------------- > Type: Technical > Reported by: Nazmus Shakeeb > > Section: 5.2. > > Original Text > ------------- > the server MUST initiate an outgoing TCP connection. The local endpoint is the relayed transport address associated with the allocation. > > Corrected Text > -------------- > the server MUST initiate an outgoing TCP connection. This connection MUST NOT be made using the relayed transport address associated with the allocation. > > Notes > ----- > if you send connect request using the allocated port then port the will not be in listen mode and this will prevent incoming tcp connection on this port. > > this will cause major problem while doing ice check. The effect is so bad that > > it may cause 97% call failure while using turn tcp behind nat. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6062 (draft-ietf-behave-turn-tcp-07) > -------------------------------------- > Title : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations > Publication Date : November 2010 > Author(s) : S. Perreault, Ed., J. Rosenberg > Category : PROPOSED STANDARD > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG > From wes@mti-systems.com Wed Jan 23 21:22:17 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27D921F8856 for ; Wed, 23 Jan 2013 21:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzurhMzkNXj0 for ; Wed, 23 Jan 2013 21:22:16 -0800 (PST) Received: from atl4mhob13.myregisteredsite.com (atl4mhob13.myregisteredsite.com [209.17.115.51]) by ietfa.amsl.com (Postfix) with ESMTP id B623621F884C for ; Wed, 23 Jan 2013 21:22:15 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob13.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r0O5MEsj023826 for ; Thu, 24 Jan 2013 00:22:14 -0500 Received: (qmail 25102 invoked by uid 0); 24 Jan 2013 05:22:12 -0000 Received: from unknown (HELO ?172.17.89.224?) (wes@mti-systems.com@12.161.62.194) by 0 with ESMTPA; 24 Jan 2013 05:22:12 -0000 Message-ID: <5100C4F7.8010206@mti-systems.com> Date: Thu, 24 Jan 2013 00:21:59 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "behave@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] AD review of nat64-discovery-heuristic document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 05:22:17 -0000 As you might have seen, draft-ietf-behave-nat64-discovery-heuristic is in IETF Last Call now. My AD Review of it resulted in a complete No-Op. I couldn't find anything to criticize, it was well written, and the shepherd review from the chairs had exactly the needed information. So, many thanks to the WG, authors, and chairs on this one! -- Wes Eddy MTI Systems From dthaler@microsoft.com Wed Jan 23 22:06:10 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6353F21F8740 for ; Wed, 23 Jan 2013 22:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Luxgq51CtqP for ; Wed, 23 Jan 2013 22:06:05 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.26]) by ietfa.amsl.com (Postfix) with ESMTP id 50BF121F8712 for ; Wed, 23 Jan 2013 22:06:03 -0800 (PST) Received: from BL2FFO11FD011.protection.gbl (10.173.161.201) by BL2FFO11HUB023.protection.gbl (10.173.161.47) with Microsoft SMTP Server (TLS) id 15.0.596.13; Thu, 24 Jan 2013 06:05:55 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Thu, 24 Jan 2013 06:05:55 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 24 Jan 2013 06:05:30 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.328.11; Wed, 23 Jan 2013 22:05:30 -0800 Received: from TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com ([169.254.5.180]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0328.011; Wed, 23 Jan 2013 22:05:30 -0800 From: Dave Thaler To: Wesley Eddy Thread-Topic: [BEHAVE] AD review of nat64-discovery-heuristic document Thread-Index: AQHN+fLdgeENY77G0kuAbvlUZtFW8JhX/agw Date: Thu, 24 Jan 2013 06:05:28 +0000 Message-ID: <341064315C6D0D498193B256F238CF97318DE4@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com> References: <5100C4F7.8010206@mti-systems.com> In-Reply-To: <5100C4F7.8010206@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(377454001)(189002)(66654001)(199002)(51704002)(5343655001)(23726001)(53806001)(4396001)(16406001)(50986001)(47976001)(47736001)(50466001)(79102001)(49866001)(33656001)(51856001)(56776001)(47776002)(55846006)(63696002)(54356001)(76482001)(54316002)(16796002)(31966008)(46406002)(74502001)(56816002)(44976002)(47446002)(46102001)(59766001)(74662001)(77982001)(48284001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB023; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 073631BD3D Cc: "behave@ietf.org" Subject: Re: [BEHAVE] AD review of nat64-discovery-heuristic document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 06:06:10 -0000 Thanks Wes! -Dave > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Wesley Eddy > Sent: Wednesday, January 23, 2013 9:22 PM > To: behave@ietf.org > Subject: [BEHAVE] AD review of nat64-discovery-heuristic document >=20 > As you might have seen, draft-ietf-behave-nat64-discovery-heuristic > is in IETF Last Call now. >=20 > My AD Review of it resulted in a complete No-Op. I couldn't find anythin= g to > criticize, it was well written, and the shepherd review from the chairs h= ad > exactly the needed information. So, many thanks to the WG, authors, and > chairs on this one! >=20 > -- > Wes Eddy > MTI Systems > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From wwwrun@rfc-editor.org Wed Jan 23 22:13:15 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118B521F8945 for ; Wed, 23 Jan 2013 22:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.308 X-Spam-Level: X-Spam-Status: No, score=-102.308 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPs3mlxd6O0d for ; Wed, 23 Jan 2013 22:13:14 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 893D121F8941 for ; Wed, 23 Jan 2013 22:13:14 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D5533B1E002; Wed, 23 Jan 2013 22:01:55 -0800 (PST) To: simon.perreault@viagenie.ca, jdrosen@jdrosen.net, wes@mti-systems.com, martin.stiemerling@neclab.eu, dwing@cisco.com, dthaler@microsoft.com From: RFC Errata System Message-Id: <20130124060156.D5533B1E002@rfc-editor.org> Date: Wed, 23 Jan 2013 22:01:55 -0800 (PST) Cc: behave@ietf.org, shakeeb@engr.eyeball.com, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Editorial Errata Reported] RFC6062 (3469) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 06:13:15 -0000 The following errata report has been submitted for RFC6062, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6062&eid=3469 -------------------------------------- Type: Editorial Reported by: Nazmus Shakeeb Section: 5.2. Original Text ------------- The server MUST buffer any data received from the client. Corrected Text -------------- The server MUST buffer any data received from the peer. Notes ----- Server doesn't need to buffer client's data because client always creates data connection with the Server after the connection is established with peer. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6062 (draft-ietf-behave-turn-tcp-07) -------------------------------------- Title : Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations Publication Date : November 2010 Author(s) : S. Perreault, Ed., J. Rosenberg Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From simon.perreault@viagenie.ca Thu Jan 24 01:11:38 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0122D21F8588 for ; Thu, 24 Jan 2013 01:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9uJeux81nu4 for ; Thu, 24 Jan 2013 01:11:37 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C3B4721F8503 for ; Thu, 24 Jan 2013 01:11:36 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4008:ad5e:13e3:3f75:3e52]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 37C7E403B8; Thu, 24 Jan 2013 04:11:35 -0500 (EST) Message-ID: <5100FAF9.9060209@viagenie.ca> Date: Thu, 24 Jan 2013 10:12:25 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: RFC Errata System References: <20130124060156.D5533B1E002@rfc-editor.org> In-Reply-To: <20130124060156.D5533B1E002@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org, jdrosen@jdrosen.net, dthaler@microsoft.com, wes@mti-systems.com, dwing@cisco.com, martin.stiemerling@neclab.eu, shakeeb@engr.eyeball.com Subject: Re: [BEHAVE] [Editorial Errata Reported] RFC6062 (3469) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:11:38 -0000 Le 2013-01-24 07:01, RFC Errata System a écrit : > Original Text > ------------- > The server MUST buffer any data received from the client. > > Corrected Text > -------------- > The server MUST buffer any data received from the peer. This is correct. > Notes > ----- > Server doesn't need to buffer client's data because client always creates data > connection with the Server after the connection is established with peer. But this explanation is wrong. The correct explanation for this errata is simpler: it's a typo. Simon From teemu.savolainen@nokia.com Thu Jan 24 01:59:37 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4EF21F86B2 for ; Thu, 24 Jan 2013 01:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWxih2mzW2Tw for ; Thu, 24 Jan 2013 01:59:37 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3E68721F8566 for ; Thu, 24 Jan 2013 01:59:37 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0O9xU2O006517; Thu, 24 Jan 2013 11:59:32 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jan 2013 11:59:31 +0200 Received: from 008-AM1MPN1-052.mgdnok.nokia.com ([169.254.2.97]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.02.0318.003; Thu, 24 Jan 2013 09:59:31 +0000 From: To: , Thread-Topic: [BEHAVE] AD review of nat64-discovery-heuristic document Thread-Index: AQHN+fLTN2JFbp2C5k2nDdXOV52gHZhYPxtc Date: Thu, 24 Jan 2013 09:59:30 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696204571E82@008-AM1MPN1-052.mgdnok.nokia.com> References: <5100C4F7.8010206@mti-systems.com> In-Reply-To: <5100C4F7.8010206@mti-systems.com> Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_916CE6CF87173740BC8A2CE44309696204571E82008AM1MPN1052mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jan 2013 09:59:31.0684 (UTC) FILETIME=[8177A240:01CDFA19] X-Nokia-AV: Clean Subject: Re: [BEHAVE] AD review of nat64-discovery-heuristic document X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:59:37 -0000 --_000_916CE6CF87173740BC8A2CE44309696204571E82008AM1MPN1052mg_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Thank you Wes and glad to hear that was the case! Big thanks definitely go to people, including chairs, in this working group= for bringing up issues and solutions, and contributions. Let's see what th= e IETF last call brings. Best regards, Teemu Sent from Lumia 820 ________________________________ From: ext Wesley Eddy Sent: =FD24.=FD1.=FD2013 7:22 To: behave@ietf.org Subject: [BEHAVE] AD review of nat64-discovery-heuristic document As you might have seen, draft-ietf-behave-nat64-discovery-heuristic is in IETF Last Call now. My AD Review of it resulted in a complete No-Op. I couldn't find anything to criticize, it was well written, and the shepherd review from the chairs had exactly the needed information. So, many thanks to the WG, authors, and chairs on this one! -- Wes Eddy MTI Systems _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --_000_916CE6CF87173740BC8A2CE44309696204571E82008AM1MPN1052mg_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Thank you Wes= and glad to hear that was the case!

Big thanks definitely go to people, including chairs, in this working group= for bringing up issues and solutions, and contributions. Let's see what th= e IETF last call brings.

Best regards,

Teemu

Sent from Lumia 820
From: ext Wesley Eddy
Sent: =FD24= .=FD1.=FD2013 7:22
To: behave@ietf.org
Subject: [BEHA= VE] AD review of nat64-discovery-heuristic document

As you might have seen, draft-ietf-behave-nat64-di= scovery-heuristic
is in IETF Last Call now.

My AD Review of it resulted in a complete No-Op.  I couldn't find
anything to criticize, it was well written, and the shepherd review
from the chairs had exactly the needed information.  So, many thanks to the WG, authors, and chairs on this one!

--
Wes Eddy
MTI Systems
_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.o= rg/mailman/listinfo/behave
 --_000_916CE6CF87173740BC8A2CE44309696204571E82008AM1MPN1052mg_-- From acee.lindem@ericsson.com Thu Jan 24 12:17:51 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E7D21F855C for ; Thu, 24 Jan 2013 12:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSxPGovHcF3A for ; Thu, 24 Jan 2013 12:17:50 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 3805321F84C6 for ; Thu, 24 Jan 2013 12:17:50 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-0d-510196ec5e29 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8C.6D.03705.DE691015; Thu, 24 Jan 2013 21:17:49 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 15:17:48 -0500 From: Acee Lindem To: Acee Lindem Thread-Topic: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 Thread-Index: AQHN+m/gJDcluL/nsU6rJPZu3itjXA== Date: Thu, 24 Jan 2013 20:17:48 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470ABBE3@eusaamb101.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE4708637E@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE4708637E@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/signed; boundary="Apple-Mail-16-646861312"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonQfftNMZAgykfRCz+/tzKaDF14RV2 i1PvbjFb7F/ZzejA4jHl90ZWj5Yjb1k9liz5yeTx41hYAEsUl01Kak5mWWqRvl0CV8aelVMY C84bVezaPpm5gXGiQRcjJ4eEgInEid9P2CBsMYkL99YD2VwcQgJHGCXa7/9iAUkICSxnlDi6 gRPEZhPQkXj+6B8ziC0ioCXR+fY7O0gDs8AaRokZ3x6zgiSEBfIkljROY4MoypfYOmEVC4St J7H1ySkwm0VAVeLIiV1gNbwC3hJNp38BDeIAWuYt8Wy7LEiYU8BH4u+2T4wgNiPQcd9PrWEC sZkFxCVuPZnPBHG0iMTDi6ehHhCVePn4HyuErSyx5Ml+Foj6SonTXT8ZIVYJSpyc+YRlAqPo LCSjZiEpm4WkDCKuLbFs4WvmWUDXMQO9P3khI0TYVOL10Y9QtrXEjF8H2SBsRYkp3Q/ZFzBy rGLkKC1OLctNNzLcxAiMyGMSbI47GBd8sjzEKM3BoiTOG+p6IUBIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDo5jHzRrV3Cqf026iZ83/cTG+iyuZvunRsr5v4ZLHDlw7uE43ruDrM5drBxr1 3Orylacof9WTvq8543RK3imeyucX5nKocYWsapzOGXRm75OZFzlr5Zp7Mo89KnjesUXS9prC pz9zJIsCLM7IK6+JKNJJKexf4S/y+k//nojpTmfaj6VNc709X4mlOCPRUIu5qDgRAEo9khaW AgAA Cc: Dean Cheng , Alvaro Retana , "behave@ietf.org" , Mohamed Boucadair Subject: Re: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 20:17:51 -0000 --Apple-Mail-16-646861312 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All,=20 Since we haven't received any comments on the subject draft we must = assume that the BEHAVE WG is happy with its content. We will proceed to = request publication. Thanks, Acee Lindem Co-chair of the OSPF WG On Jan 5, 2013, at 6:42 AM, Acee Lindem wrote: >=20 > We have WG last called the subject draft in the OSPF WG. It describes = usage of a separate OSPFv3 instance in support of RFC 6052 address = translation.=20 > Please comment by Saturday, January 19th, 2013. Here is a URL to the = subject document:=20 >=20 > = http://www.ietf.org/id/draft-ietf-ospf-ipv4-embedded-ipv6-routing-05.txt >=20 > Thanks, > Acee=20 >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --Apple-Mail-16-646861312 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDEyNDIwMTc0N1owIwYJKoZI hvcNAQkEMRYEFHA1NBEiR+0GxLurGFcc+qlitG4EMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgDxnnvIv36BVEZjw+ewoaOFlIL0atxq1rZmF6TwyQl95sNRgleC59CiOiyd+j+3r EVlrvFGDCdwqKnvFrfQu6EbcPi/KTMi2/rjAiGyzRv4xqANDeZpfJuKEwV9w7puy45wHn88N70wx dUrYHgRPsvypZmjn4gw1ARI8Gpr/TcNQAAAAAAAA --Apple-Mail-16-646861312-- From ajs@anvilwalrusden.com Thu Jan 24 12:35:58 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3152E11E80A2 for ; Thu, 24 Jan 2013 12:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFaYqC70YGUg for ; Thu, 24 Jan 2013 12:35:57 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id BAA1F11E809B for ; Thu, 24 Jan 2013 12:35:57 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 78AED8A031 for ; Thu, 24 Jan 2013 20:35:53 +0000 (UTC) Date: Thu, 24 Jan 2013 15:35:47 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20130124203547.GA11097@mx1.yitter.info> References: <94A203EA12AECE4BA92D42DBFFE0AE4708637E@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE470ABBE3@eusaamb101.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470ABBE3@eusaamb101.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 20:35:58 -0000 On Thu, Jan 24, 2013 at 08:17:48PM +0000, Acee Lindem wrote: > Since we haven't received any comments on the subject draft we must > assume that the BEHAVE WG is happy with its content. I object to the conclusion. Non-review is not evidence of support. If you can't get five people who say they read the draft and support it, then there's no reason to suppose people think it's a good idea. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From acee.lindem@ericsson.com Thu Jan 24 12:45:45 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DDC11E80A3 for ; Thu, 24 Jan 2013 12:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZBybhv04Mwe for ; Thu, 24 Jan 2013 12:45:44 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 96D6A11E809A for ; Thu, 24 Jan 2013 12:45:44 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-6c-51019d776b54 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B5.B5.31450.77D91015; Thu, 24 Jan 2013 21:45:43 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 15:45:42 -0500 From: Acee Lindem To: Andrew Sullivan Thread-Topic: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 Thread-Index: AQHN+m/gJDcluL/nsU6rJPZu3itjXJhZQ7mAgAACwwA= Date: Thu, 24 Jan 2013 20:45:42 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470ABCF7@eusaamb101.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE4708637E@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE470ABBE3@eusaamb101.ericsson.se> <20130124203547.GA11097@mx1.yitter.info> In-Reply-To: <20130124203547.GA11097@mx1.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <15218ED789D0F14684856F8B30FAA59B@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXRPrG75XMZAg/t7VS0OfL7GZDF14RV2 ByaPZydfsXssWfKTKYApissmJTUnsyy1SN8ugSvj9N23TAUrOCpenbvM1sB4ka2LkZNDQsBE YmrjaSYIW0ziwr31QHEuDiGBI4wSr1degHKWM0r8Xt8MVsUmoCPx/NE/ZhBbBMhese4hI4jN LKAp8XRSD1iNsECexJLGaWwQNfkSWyesYoGwrSQmnZoNVs8ioCqx/N0VoBoODl4Bb4m3M7Mg du1glHj6ZzpYPaeAqcSsL9vB5jACXff91BomiF3iEreezIe6WkBiyZ7zzBC2qMTLx/9YIWxl iSVP9rNA1OtILNj9iQ3CtpaYeOAYO4StLbFs4WuwXl4BQYmTM5+wTGAUn4VkxSwk7bOQtM9C 0j4LSfsCRtZVjBylxalluelGBpsYgXF1TIJNdwfjnpeWhxilOViUxHmDXC8ECAmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamAUvRK+5G2XpLng3AmyDCGmLhaeb+8rWfllaF3sX56x/E/hbYcE Hq8Hh75N8lWcEDFrNpvp62jvzXnvmla8uF+yzr5TbMWH96+yihd1r0tJdNFn3j357zG/Jwdt MnPdWp/NkLu/pqzATjL48OnMA677K318n17V+RqRGpOvtuo8s0D0/3NZzp+UWIozEg21mIuK EwETXvqeeQIAAA== Cc: "" Subject: Re: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 20:45:45 -0000 On Jan 24, 2013, at 3:35 PM, Andrew Sullivan wrote: > On Thu, Jan 24, 2013 at 08:17:48PM +0000, Acee Lindem wrote: >> Since we haven't received any comments on the subject draft we must >> assume that the BEHAVE WG is happy with its content.=20 >=20 > I object to the conclusion. Non-review is not evidence of support. > If you can't get five people who say they read the draft and support > it, then there's no reason to suppose people think it's a good idea. Sufficient time has been provided for input and we've already gone through = several review cycles in the OSPF WG. We provided the BEHAVE the opportunit= y to comment since the draft is based on RFC 6052 (which was in my original= E-mail but clipped from your reply). You are welcome to review it as part = of the IETF last call.=20 Thanks, Acee=20 >=20 > Best, >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ajs@anvilwalrusden.com Thu Jan 24 13:22:20 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6B311E8099 for ; Thu, 24 Jan 2013 13:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgK8dysC7W3q for ; Thu, 24 Jan 2013 13:22:20 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 53AF721F85EA for ; Thu, 24 Jan 2013 13:22:20 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 6BF748A031 for ; Thu, 24 Jan 2013 21:22:14 +0000 (UTC) Date: Thu, 24 Jan 2013 16:22:12 -0500 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20130124212211.GD11097@mx1.yitter.info> References: <94A203EA12AECE4BA92D42DBFFE0AE4708637E@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE470ABBE3@eusaamb101.ericsson.se> <20130124203547.GA11097@mx1.yitter.info> <94A203EA12AECE4BA92D42DBFFE0AE470ABCF7@eusaamb101.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470ABCF7@eusaamb101.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 21:22:20 -0000 On Thu, Jan 24, 2013 at 08:45:42PM +0000, Acee Lindem wrote: > > Sufficient time has been provided for input and we've already gone through several review cycles in the OSPF WG. We provided the BEHAVE the opportunity to comment since the draft is based on RFC 6052 (which was in my original E-mail but clipped from your reply). You are welcome to review it as part of the IETF last call. > Well, I can provide this review: I don't understand the value of the proposal. As nearly as I can tell, it is a redundant mechanism that does not push existing v4-only networks towards IPv6 deployment. To the extent that's true, I don't think it should be pursued. There appear to be two use cases listed in the document, but I can't say how compelling I find them. The IETF seems to have contracted Perl disease, in that we want to have More Than One Way To Do It for every possible transition strategy. I think this is nuts. I don't especially care if the draft goes ahead, and from the peremptory tone of this thread I presume it will. But I think all this redundancy (of methods to aid in the preservation of a network technology we might properly wish would go away) is a mistake. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From acee.lindem@ericsson.com Thu Jan 24 13:45:34 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8AD11E80A5 for ; Thu, 24 Jan 2013 13:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksay-SE9Hhg3 for ; Thu, 24 Jan 2013 13:45:34 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A782E11E809B for ; Thu, 24 Jan 2013 13:45:33 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-7d-5101ab7cfb75 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BA.69.31450.C7BA1015; Thu, 24 Jan 2013 22:45:33 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 16:45:32 -0500 From: Acee Lindem To: Andrew Sullivan Thread-Topic: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 Thread-Index: AQHN+m/gJDcluL/nsU6rJPZu3itjXJhZQ7mAgAACwwCAAAo1AIAABoGA Date: Thu, 24 Jan 2013 21:45:31 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470ABEDA@eusaamb101.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE4708637E@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE470ABBE3@eusaamb101.ericsson.se> <20130124203547.GA11097@mx1.yitter.info> <94A203EA12AECE4BA92D42DBFFE0AE470ABCF7@eusaamb101.ericsson.se> <20130124212211.GD11097@mx1.yitter.info> In-Reply-To: <20130124212211.GD11097@mx1.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <7AB9D7C734E9CE419717E6DBC05477BB@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXRPgm7tasZAg4eH2CwOfL7GZDF14RV2 ByaPZydfsXssWfKTKYApissmJTUnsyy1SN8ugSvj2ZapbAVLOCpmvWlibGA8xNbFyMkhIWAi MbOzlwnCFpO4cG89UJyLQ0jgCKPEvM8TWCCc5YwSV/vmsYNUsQnoSDx/9I8ZxBYBslese8gI YjMLaEo8ndQDNklYIE9iSeM0NoiafImtE1axQNhuEstO3WEFsVkEVCUmLrsNNJODg1fAW+LB 6QiIXUuZJH5O+A42h1PAVKKjqRlsLyPQdd9PrWGC2CUucevJfKirBSSW7DnPDGGLSrx8/I8V wlaWWPJkPwtEvY7Egt2f2CBsa4mr29cxQ9jaEssWvgazeQUEJU7OfMIygVF8FpIVs5C0z0LS PgtJ+ywk7QsYWVcxcpQWp5blphsZbGIExtUxCTbdHYx7XloeYpTmYFES5w1yvRAgJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgVHrt01bWJzgL4lPKXHTYwxSfyuHT1q3z9g0eZ2A4Ixv7Kkz 4gW+HXW+8c/WXv/YSesdStbnNhyXrHeVVZlV18AjL1J62e/vF9GNNWzpHpsOWFyvUODsXiXy xrZ+k9W05Wv5GR4cXeCTsmTLg6pd22Z2BvjvFH8dLn4mX6Khf45Fa3+5fbrxRyWW4oxEQy3m ouJEABuCISR5AgAA Cc: "" Subject: Re: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 21:45:34 -0000 On Jan 24, 2013, at 4:22 PM, Andrew Sullivan wrote: > On Thu, Jan 24, 2013 at 08:45:42PM +0000, Acee Lindem wrote: >>=20 >> Sufficient time has been provided for input and we've already gone throu= gh several review cycles in the OSPF WG. We provided the BEHAVE the opportu= nity to comment since the draft is based on RFC 6052 (which was in my origi= nal E-mail but clipped from your reply). You are welcome to review it as pa= rt of the IETF last call.=20 >>=20 >=20 > Well, I can provide this review: I don't understand the value of the > proposal. >=20 > As nearly as I can tell, it is a redundant mechanism that does not > push existing v4-only networks towards IPv6 deployment. To the extent > that's true, I don't think it should be pursued. Using this reasoning, the same could be said for RFC 6052 and RFC 6145. Giv= en that the RFC 6052/RFC 6145 mechanisms exist, this is merely an informati= onal draft describing how one could use OSPFv3 address families to route be= tween the IPv4 and IPv6 domains.=20 Acee=20 From moore@network-heretics.com Thu Jan 24 23:13:54 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D5A21F84D1 for ; Thu, 24 Jan 2013 23:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lSYWEyFbWlN for ; Thu, 24 Jan 2013 23:13:53 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id C64FB21F84CC for ; Thu, 24 Jan 2013 23:13:52 -0800 (PST) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 0652120922 for ; Fri, 25 Jan 2013 02:13:52 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 25 Jan 2013 02:13:52 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=jkr6tPw0HOhecHV7MNvmZp dixYk=; b=s8AvY4Okzr5KNgQ9dIO8Ifn94iFt2FTCsCq9xBk/c665uTGzAvnvuG nO/HXIjOGWhYXwbdHyljHrzueiJGEkRSbgBxcJ25fIn99jL7U6QcquiDM+vKLUZC 4I8B0I/dBuF4urVLyx89MyyuoCQF+avjnAMGgGiaOf7HuO5K5a5bI= X-Sasl-enc: s8ajImTF3zcCK4tNCs400LrjfYezfa0WSEzq9bQ3Ol2j 1359098031 Received: from [192.168.1.20] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 0757E4827DE; Fri, 25 Jan 2013 02:13:50 -0500 (EST) Message-ID: <510230AC.5070606@network-heretics.com> Date: Fri, 25 Jan 2013 02:13:48 -0500 From: Keith Moore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: behave@ietf.org References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> <50F43ED1.4020704@viagenie.ca> In-Reply-To: <50F43ED1.4020704@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 07:13:54 -0000 On 01/14/2013 12:22 PM, Simon Perreault wrote: > Le 2013-01-14 14:14, Iljitsch van Beijnum a écrit : >> However, it doesn't seem too difficult to make protocol 41 NATing >> work: simply use the embedded IPv6 destination address for >> demultiplexing. With this in place, existing IPv6-enabled home >> gateways could talk to existing tunnel brokers (tunnelbroker.net, >> sixxs.net) even though there's a carrier grade NAT in the middle. > > BCP: don't use proto 41 behind a NAT. BCP: don't use NAT. At all. Keith From iljitsch@muada.com Fri Jan 25 05:25:33 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E5C21F8445 for ; Fri, 25 Jan 2013 05:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.285 X-Spam-Level: X-Spam-Status: No, score=-102.285 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXLR-BiOuQsl for ; Fri, 25 Jan 2013 05:25:33 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id D29C721F85C0 for ; Fri, 25 Jan 2013 05:25:32 -0800 (PST) Received: from [IPv6:2001:470:1f0b:1289:f5af:a853:c19a:c861] ([IPv6:2001:470:1f0b:1289:f5af:a853:c19a:c861]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r0PDLFG5058393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Jan 2013 14:21:15 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <50F43ED1.4020704@viagenie.ca> Date: Fri, 25 Jan 2013 14:25:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> <50F43ED1.4020704@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1499) Cc: behave@ietf.org Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 13:25:33 -0000 On 14 jan 2013, at 18:22, Simon Perreault = wrote: > BCP: don't use proto 41 behind a NAT. > Use an IPv6 tunnelling protocol that supports NAT. > E.g.: TSP [RFC5572], which is used at freenet6.net. I find it annoying that pretty much all comments miss the point that = NATting protocol 41 allows EXISTING implementations to keep working. I gather that there aren't even two different interoperating = implementations of TSP. There are dozens, if not hundreds, of millions = of devices out there that can do protocol 41 out of the box.= From marc.blanchet@viagenie.ca Fri Jan 25 05:45:24 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B0521F884A for ; Fri, 25 Jan 2013 05:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lgq3tvg1PU3C for ; Fri, 25 Jan 2013 05:45:24 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0537721F8849 for ; Fri, 25 Jan 2013 05:45:24 -0800 (PST) Received: from mb.lan (modemcable180.211-203-24.mc.videotron.ca [24.203.211.180]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 804F146F53; Fri, 25 Jan 2013 08:45:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: Date: Fri, 25 Jan 2013 08:45:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> <50F43ED1.4020704@viagenie.ca> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1283) Cc: behave@ietf.org Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 13:45:25 -0000 Le 2013-01-25 =E0 08:25, Iljitsch van Beijnum a =E9crit : > On 14 jan 2013, at 18:22, Simon Perreault = wrote: >=20 >> BCP: don't use proto 41 behind a NAT. >=20 >> Use an IPv6 tunnelling protocol that supports NAT. >> E.g.: TSP [RFC5572], which is used at freenet6.net. >=20 > I find it annoying that pretty much all comments miss the point that = NATting protocol 41 allows EXISTING implementations to keep working. >=20 > I gather that there aren't even two different interoperating = implementations of TSP. There are dozens, if not hundreds, of millions = of devices out there that can do protocol 41 out of the box. maybe, but: a) not that many have their vendor firmware configurable to do that. b) even if they do, that is far from the normal end-user can do. c) only real use case is the geek who is running openwrt/dd/... or knows = enough to configure a proto 41 tunnel. So at the end, the c) use case is able to use TSP, which requires no = modification to the CGNs. Moreover, long reach tunnels do not provide a best experience. With = happy eyeballs being deployed, the v6 side will always loose. Short = range tunnels are good, especially when the tunnel concentrator is in = your upstream provider network. Then it makes more sense: deployments of = these have been done using 6to4pmt, 6rd, TSP or else. In this context, = since it is a service provided by the ISP, then it can locate the tunnel = concentrator in the non-cgn part of the network. I fail to see a good use case for your proposal, except for some real = geek corner cases. Marc. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From marka@isc.org Fri Jan 25 06:09:28 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE29D21F87D5 for ; Fri, 25 Jan 2013 06:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpxQmqiF9NOM for ; Fri, 25 Jan 2013 06:09:28 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id C448221F8468 for ; Fri, 25 Jan 2013 06:09:27 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 2513E5F9903; Fri, 25 Jan 2013 14:09:16 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1359122966; bh=LExqXJG0NGEFOrQzBqm1htS/29etrrXAomjMqDH+TkE=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=YZl0a3FxssGhJTo98bUMq5fDe/yx/7O4ai11p6rZPkiv/bdPVjrHG28rcInc0ujzn rtz8rY7IUsU/AVrhVkP9BhIIBUMhag+Q0X15vzdXvY9oU8tSerdpezH0K7bqAEtIGz W+76pT53Tke3wePzt/pprq3C/xVdmVxe5sL8w+ks= Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 823AD216C3B; Fri, 25 Jan 2013 14:09:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 62F512E741B3; Sat, 26 Jan 2013 01:09:08 +1100 (EST) To: Iljitsch van Beijnum From: Mark Andrews References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> <50F43ED1.4020704@viagenie.ca> In-reply-to: Your message of "Fri, 25 Jan 2013 14:25:31 BST." Date: Sat, 26 Jan 2013 01:09:07 +1100 Message-Id: <20130125140908.62F512E741B3@drugs.dv.isc.org> Cc: behave@ietf.org Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 14:09:28 -0000 In message , Iljitsch van Beijn um writes: > On 14 jan 2013, at 18:22, Simon Perreault wrote > : > > > BCP: don't use proto 41 behind a NAT. > > > Use an IPv6 tunnelling protocol that supports NAT. > > E.g.: TSP [RFC5572], which is used at freenet6.net. > > I find it annoying that pretty much all comments miss the point that NATting > protocol 41 allows EXISTING implementations to keep working. I'm curious. Say you have two tunnels both going to the same router. How does the NAT learn which IPv6 prefixes are associated with which internal addresses. Remember these tunnels are often up for months at a time with both external and internally initiated traffic? Today I re-establish my HE tunnel whenever the DHCP lease updates the IPv4 address. There is a /128 and a /64 associated with that tunnel. I have both externally and internally initiated traffic. The tunnel re-establishment is done over https. I can use "auto" for my local IPv4 address and the tunnel broker will look at the IPv4 address of the https session to fill in my IPv4 address. So for this to work the NAT would need to detect the https session and the force protocol 41 traffic to use the same IPv4 address. If there was another internal machine talking to the same tunnel broker it would also need to learn the prefixes associated with each tunnel. Now I suppose the NAT could have a list of tunnel broker addresses and ensure that no internal machines used the same external address when talking to a particular tunnel broker but it would be fragile to the extreme. This is just one use of protocol 41. The simplest thing is to look to see who is using protocol 41 and just not put them behind a CGN or wire down the internal/external address mappings for these customers similar to a DMZ host. Other clients can still share the address but all protocol 41 traffic goes to internal client with the fixed mapping. > I gather that there aren't even two different interoperating implementations > of TSP. There are dozens, if not hundreds, of millions of devices out there t > hat can do protocol 41 out of the box. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Fri Jan 25 06:21:47 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C13D21F8734 for ; Fri, 25 Jan 2013 06:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ohv65B6WrS1y for ; Fri, 25 Jan 2013 06:21:41 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id C49A521F854F for ; Fri, 25 Jan 2013 06:21:40 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 2DEB7C94F9; Fri, 25 Jan 2013 14:21:32 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1359123699; bh=SeMVfbrk0XDAn8iJk9hHYpw9CC0Td92xc7af2WiGaPg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=tREBmRIcHB0ty8y+hbpA77eEdzUB6AYlKsNvQmmpaGFGUVPd8xghv81tsMNgO9ktN L8omiKh6+rZxfHsAaiFWNp8EMusQ605SZO5cqzpnHXg8QAJKmRe0scxPkAUKLSESlR k21nQS91gD5P7Ve/TAAXKXsmNUuXPOblt92Hl0II= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Fri, 25 Jan 2013 14:21:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4ac:5e21:2afe:9e9d]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E3A9A216C43; Fri, 25 Jan 2013 14:21:31 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 8A5D42E742AA; Sat, 26 Jan 2013 01:21:29 +1100 (EST) To: Marc Blanchet From: Mark Andrews References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> <50F43ED1.4020704@viagenie.ca> In-reply-to: Your message of "Fri, 25 Jan 2013 08:45:23 CDT." Date: Sat, 26 Jan 2013 01:21:29 +1100 Message-Id: <20130125142129.8A5D42E742AA@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: behave@ietf.org Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 14:21:48 -0000 In message , Marc Blanchet wr ites: > > Le 2013-01-25 =E0 08:25, Iljitsch van Beijnum a =E9crit : > > > On 14 jan 2013, at 18:22, Simon Perreault w= > rote: > > = > > >> BCP: don't use proto 41 behind a NAT. > > = > > >> Use an IPv6 tunnelling protocol that supports NAT. > >> E.g.: TSP [RFC5572], which is used at freenet6.net. > > = > > > I find it annoying that pretty much all comments miss the point that NATt= > ing protocol 41 allows EXISTING implementations to keep working. > > = > > > I gather that there aren't even two different interoperating implementati= > ons of TSP. There are dozens, if not hundreds, of millions of devices out t= > here that can do protocol 41 out of the box. > > maybe, but: > a) not that many have their vendor firmware configurable to do that. > b) even if they do, that is far from the normal end-user can do. > c) only real use case is the geek who is running openwrt/dd/... or knows en= > ough to configure a proto 41 tunnel. > > So at the end, the c) use case is able to use TSP, which requires no modifi= > cation to the CGNs. > > Moreover, long reach tunnels do not provide a best experience. With happy e= > yeballs being deployed, the v6 side will always loose. This statement is demonstatably false. I have a long range tunnel (Sydney/Palo Alto). 63% of my external traffic is IPv6 and goes over it even *with* happy eyeballs in play. There is not significant difference between IPv4 and IPv6 when talking to the US, Europe or any IPv4 destination that I would normally route to via the US for me. My IPv4 path to the US also goes via Palo Alto. This is not to say tunnel end point selection is not important or I wouldn't prefer a more local one. > Short range tunnels = > are good, especially when the tunnel concentrator is in your upstream provi= > der network. Then it makes more sense: deployments of these have been done = > using 6to4pmt, 6rd, TSP or else. In this context, since it is a service pr= > ovided by the ISP, then it can locate the tunnel concentrator in the non-cg= > n part of the network. > > I fail to see a good use case for your proposal, except for some real geek = > corner cases. > > Marc. > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marc.blanchet@viagenie.ca Fri Jan 25 07:10:35 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0A921F881D for ; Fri, 25 Jan 2013 07:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.381 X-Spam-Level: X-Spam-Status: No, score=-102.381 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiHF8kGknYjb for ; Fri, 25 Jan 2013 07:10:35 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAB921F888E for ; Fri, 25 Jan 2013 07:10:35 -0800 (PST) Received: from h114.viagenie.ca (h114.viagenie.ca [206.123.31.114]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B721840367; Fri, 25 Jan 2013 10:10:34 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Marc Blanchet In-Reply-To: <20130125142129.8A5D42E742AA@drugs.dv.isc.org> Date: Fri, 25 Jan 2013 10:10:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <83087F5E-2E30-444C-A420-E1118CE0166D@viagenie.ca> References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> <50F43ED1.4020704@viagenie.ca> <20130125142129.8A5D42E742AA@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1283) Cc: behave@ietf.org Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:10:36 -0000 Le 2013-01-25 =E0 09:21, Mark Andrews a =E9crit : >=20 > In message , Marc = Blanchet wr > ites: >>=20 >> Le 2013-01-25 =3DE0 08:25, Iljitsch van Beijnum a =3DE9crit : >>=20 >>> On 14 jan 2013, at 18:22, Simon Perreault = w=3D >> rote: >>> =3D >>=20 >>>> BCP: don't use proto 41 behind a NAT. >>> =3D >>=20 >>>> Use an IPv6 tunnelling protocol that supports NAT. >>>> E.g.: TSP [RFC5572], which is used at freenet6.net. >>> =3D >>=20 >>> I find it annoying that pretty much all comments miss the point that = NATt=3D >> ing protocol 41 allows EXISTING implementations to keep working. >>> =3D >>=20 >>> I gather that there aren't even two different interoperating = implementati=3D >> ons of TSP. There are dozens, if not hundreds, of millions of devices = out t=3D >> here that can do protocol 41 out of the box. >>=20 >> maybe, but: >> a) not that many have their vendor firmware configurable to do that. >> b) even if they do, that is far from the normal end-user can do. >> c) only real use case is the geek who is running openwrt/dd/... or = knows en=3D >> ough to configure a proto 41 tunnel. >>=20 >> So at the end, the c) use case is able to use TSP, which requires no = modifi=3D >> cation to the CGNs. >>=20 >> Moreover, long reach tunnels do not provide a best experience. With = happy e=3D >> yeballs being deployed, the v6 side will always loose. >=20 > This statement is demonstatably false. well=85 I would rephrase my statement as: depending on your trafic = pattern and the v4/v6 topology differences between the two tunnels = endpoints. Marc. > I have a long range tunnel > (Sydney/Palo Alto). 63% of my external traffic is IPv6 and goes > over it even *with* happy eyeballs in play. There is not significant > difference between IPv4 and IPv6 when talking to the US, Europe or > any IPv4 destination that I would normally route to via the US for > me. My IPv4 path to the US also goes via Palo Alto. >=20 > This is not to say tunnel end point selection is not important or > I wouldn't prefer a more local one. >=20 >> Short range tunnels =3D >> are good, especially when the tunnel concentrator is in your upstream = provi=3D >> der network. Then it makes more sense: deployments of these have been = done =3D >> using 6to4pmt, 6rd, TSP or else. In this context, since it is a = service pr=3D >> ovided by the ISP, then it can locate the tunnel concentrator in the = non-cg=3D >> n part of the network. >>=20 >> I fail to see a good use case for your proposal, except for some real = geek =3D >> corner cases. >>=20 >> Marc. >>=20 >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From iljitsch@muada.com Fri Jan 25 08:47:49 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89D121F8884 for ; Fri, 25 Jan 2013 08:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g3qr4HyCMhV for ; Fri, 25 Jan 2013 08:47:49 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id A951B21F8878 for ; Fri, 25 Jan 2013 08:47:48 -0800 (PST) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r0PGhWRM059728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Jan 2013 17:43:32 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <20130125140908.62F512E741B3@drugs.dv.isc.org> Date: Fri, 25 Jan 2013 17:47:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> <50F43ED1.4020704@viagenie.ca> <20130125140908.62F512E741B3@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) Cc: behave@ietf.org Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 16:47:49 -0000 On 25 jan 2013, at 15:09, Mark Andrews wrote: > I'm curious. Say you have two tunnels both going to the same router. > How does the NAT learn which IPv6 prefixes are associated with which > internal addresses. Remember these tunnels are often up for months > at a time with both external and internally initiated traffic? By looking at the IPv6 source addresses in the inner IPv6 header and = creating state based on those. Then when packets arrive from the = outside, get the destination IPv6 address from the inner IPv6 header, = and determine the IPv4 address to translate to from the NAT table. Ideally, this would be a dynamic longest match first, so a single = address can set up a mapping for an entire /48 or /56 until a different = host uses an address in a different /64 but in the same /48 or /56. Doing this all the way up to /128 is more robust against spoofing = attacks, but less robust against NAT state exhaustion attacks. > So for this to work the NAT would need to detect the https session > and the force protocol 41 traffic to use the same IPv4 address. No, that doesn't work. The issue with protocol 41 is that it has no port = numbers, so without looking inside the inner IPv6 header, there's = nothing to demultiplex packets towards different users behind the same = NAT. A different solution would be an extra encapsulation that is used = between the tunnel broker and the CGN.= From marka@isc.org Fri Jan 25 15:59:08 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CC321F88A6 for ; Fri, 25 Jan 2013 15:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGfSYhQlVEIJ for ; Fri, 25 Jan 2013 15:59:07 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 6035621F888B for ; Fri, 25 Jan 2013 15:59:07 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id BF98FC951E; Fri, 25 Jan 2013 23:58:58 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1359158346; bh=Qc1nxvdetjwsVNhVN9Pqqo+FECU05FMRuO7Tu+DH0Yw=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=m4OGlbTLrCJVw5kiCUiUKdOJr/sCrb+EwVPYhy1/YvHJ5JjHb7pQ2hgmO+wQWhZsJ 24ZpPqf+V3S5RpoOm8ykzakuBJndtQmCHR+LuhfUS9tVGxVrQa4bej4ortgWeDQTkG ZuzL9S2FViKoyhC+Jz9RmxQQsZEf4+CHYADntRVk= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Fri, 25 Jan 2013 23:58:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:4958:7557:c1b0:9e93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 79D50216C40; Fri, 25 Jan 2013 23:58:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0F8AB2E75690; Sat, 26 Jan 2013 10:58:55 +1100 (EST) To: Iljitsch van Beijnum From: Mark Andrews References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> <50F43ED1.4020704@viagenie.ca> <20130125140908.62F512E741B3@drugs.dv.isc.org> In-reply-to: Your message of "Fri, 25 Jan 2013 17:47:44 BST." Date: Sat, 26 Jan 2013 10:58:54 +1100 Message-Id: <20130125235855.0F8AB2E75690@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: behave@ietf.org Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 23:59:08 -0000 In message , Iljitsch van Beijn um writes: > On 25 jan 2013, at 15:09, Mark Andrews wrote: > > > I'm curious. Say you have two tunnels both going to the same router. > > How does the NAT learn which IPv6 prefixes are associated with which > > internal addresses. Remember these tunnels are often up for months > > at a time with both external and internally initiated traffic? > > By looking at the IPv6 source addresses in the inner IPv6 header and creating > state based on those. Then when packets arrive from the outside, get the des > tination IPv6 address from the inner IPv6 header, and determine the IPv4 addr > ess to translate to from the NAT table. > > Ideally, this would be a dynamic longest match first, so a single address can > set up a mapping for an entire /48 or /56 until a different host uses an add > ress in a different /64 but in the same /48 or /56. Which will result in packets being sent to the wrong internal machine. > Doing this all the way up to /128 is more robust against spoofing attacks, bu > t less robust against NAT state exhaustion attacks. > > > So for this to work the NAT would need to detect the https session > > and the force protocol 41 traffic to use the same IPv4 address. > > No, that doesn't work. The issue with protocol 41 is that it has no port numb > ers, so without looking inside the inner IPv6 header, there's nothing to demu > ltiplex packets towards different users behind the same NAT. And I'm showing you how protocol 41 tunnels are established today. You are the one claiming that this will work with existing setups. Today the https source address and the protocol 41 source address are constrained to be the same address 99.99% of the time as the customer has a single IPv4 address. This relationship is used by the tunnel establishment process. With CGN there is no such required relationship. Additionally the relationship can change without the endpoints being aware of the change. Tunnels are not transient connections. They are long term connections and cause all the sorts of issues that long running TCP sessions have with NATs. > A different solution would be an extra encapsulation that is used between the > tunnel broker and the CGN. > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Sat Jan 26 08:12:40 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F264221F8206 for ; Sat, 26 Jan 2013 08:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.525 X-Spam-Level: X-Spam-Status: No, score=-101.525 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACzXqVQzm18t for ; Sat, 26 Jan 2013 08:12:39 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 396B121F8432 for ; Sat, 26 Jan 2013 08:12:39 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hq7so376673wib.1 for ; Sat, 26 Jan 2013 08:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ypBLtyjtxpFeLoXvrGFwVLft8luKMBmhEjK7eFXn3MI=; b=ExqN0vYmx3LKKUknQqR26bCoaFX3IMPMzI1+eAf3f31uoJviacne24599fJwuwE+eT Jc8Wne2rPRKkt2j4z4xwtaE0ZYF1aFyfhSZFUQNQuQVM4dG4zaz1TWExCMFxtbL0G5Wr fjFe5FIKQ4FEffpgmNpFxc3VY3Zmt1XdwvpAZj15HicpVTnC85PD7ABc+3qFU+m6DCLy VR231IMKbtw43g3rD2GZU/GErNEJuTQwahW4YhrIlpWs5hUO/Nkd+5JbZTZHqg/6xCF9 1YrzFwIqgfeNmos4IIU43vTtlx6AzMMOfIweWFRqGh4tFN2cF5V8sYNvTOvgZ9SSQZrQ l9dg== X-Received: by 10.194.87.200 with SMTP id ba8mr13895713wjb.22.1359216754494; Sat, 26 Jan 2013 08:12:34 -0800 (PST) Received: from [192.168.1.65] (host-2-102-216-163.as13285.net. [2.102.216.163]) by mx.google.com with ESMTPS id gz3sm3274463wib.2.2013.01.26.08.12.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jan 2013 08:12:32 -0800 (PST) Message-ID: <51040083.3080600@gmail.com> Date: Sat, 26 Jan 2013 16:12:51 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Acee Lindem References: <94A203EA12AECE4BA92D42DBFFE0AE4708637E@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE470ABBE3@eusaamb101.ericsson.se> <20130124203547.GA11097@mx1.yitter.info> <94A203EA12AECE4BA92D42DBFFE0AE470ABCF7@eusaamb101.ericsson.se> <20130124212211.GD11097@mx1.yitter.info> <94A203EA12AECE4BA92D42DBFFE0AE470ABEDA@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE470ABEDA@eusaamb101.ericsson.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" , Andrew Sullivan Subject: Re: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 16:12:40 -0000 On 24/01/2013 21:45, Acee Lindem wrote: > On Jan 24, 2013, at 4:22 PM, Andrew Sullivan wrote: > >> On Thu, Jan 24, 2013 at 08:45:42PM +0000, Acee Lindem wrote: >>> Sufficient time has been provided for input and we've already gone through several review cycles in the OSPF WG. We provided the BEHAVE the opportunity to comment since the draft is based on RFC 6052 (which was in my original E-mail but clipped from your reply). You are welcome to review it as part of the IETF last call. >>> >> Well, I can provide this review: I don't understand the value of the >> proposal. >> >> As nearly as I can tell, it is a redundant mechanism that does not >> push existing v4-only networks towards IPv6 deployment. To the extent >> that's true, I don't think it should be pursued. > > Using this reasoning, the same could be said for RFC 6052 and RFC 6145. Given that the RFC 6052/RFC 6145 mechanisms exist, this is merely an informational draft describing how one could use OSPFv3 address families to route between the IPv4 and IPv6 domains. I think the problem is that the scenario analysis isn't adequate. There is no discussion of the relationship with the various scenarios described in RFC 6144 - this seems to be an extension from there, but it should be explained. It would be nice to hear how it compares to draft-ietf-v6ops-464xlat. The latter is not aimed at IPv4 peer-to-peer communication, but only at client-server with no inbound connections. Is this different? Given that "the IPv4 and IPv6 header translation performed in both directions by the AFXLBR is stateless", does that imply that only global IPv4 addresses are supported and the solution is transparent to ports and upper layers? Brian From acee.lindem@ericsson.com Sat Jan 26 08:54:57 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB1021F88BF for ; Sat, 26 Jan 2013 08:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lb5N0rwExcZQ for ; Sat, 26 Jan 2013 08:54:57 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5E20121F88BD for ; Sat, 26 Jan 2013 08:54:57 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-ba-51040a6009a0 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 6B.26.03705.06A04015; Sat, 26 Jan 2013 17:54:56 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Sat, 26 Jan 2013 11:54:56 -0500 From: Acee Lindem To: Brian E Carpenter Thread-Topic: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 Thread-Index: AQHN+m/gJDcluL/nsU6rJPZu3itjXJhZQ7mAgAACwwCAAAo1AIAABoGAgALHuoCAAAu/gA== Date: Sat, 26 Jan 2013 16:54:55 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470AF742@eusaamb101.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE4708637E@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE470ABBE3@eusaamb101.ericsson.se> <20130124203547.GA11097@mx1.yitter.info> <94A203EA12AECE4BA92D42DBFFE0AE470ABCF7@eusaamb101.ericsson.se> <20130124212211.GD11097@mx1.yitter.info> <94A203EA12AECE4BA92D42DBFFE0AE470ABEDA@eusaamb101.ericsson.se> <51040083.3080600@gmail.com> In-Reply-To: <51040083.3080600@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZXLonRDeBiyXQ4P1fLYsDn68xWfz9uZXR YurCK+wWbRf3MVmceneL2WL/ym5GBzaPZydfsXtM+b2R1WPnrLvsHi1H3rJ6LFnyk8njx7Gw ALYoLpuU1JzMstQifbsEroym5TdYC2bxV7y4uZy9gXECTxcjJ4eEgInEgY/HmSFsMYkL99az dTFycQgJHGGUmPhgPQuEs5xRovXjdTaQKjYBHYnnj/6BdYgIGEs0dp1mBSliFrjGKDH933yw hLBAnsSSxmlsEEX5ElsnrGKBsMMkdv7eDGazCKhKtHyaC2bzCnhLHF/VxQixrY1Z4vf6/2DN nAKaEu/nXGIEsRmB7vt+ag0TiM0sIC5x68l8Joi7BSSW7DkP9YOoxMvH/1ghbGWJ73MesUDU 60gs2P2JDcK2lnh6uZ8dwtaWWLbwNTPEEYISJ2c+YZnAKD4LyYpZSNpnIWmfhaR9FpL2BYys qxg5SotTy3LTjQw3MQIj9ZgEm+MOxgWfLA8xSnOwKInzhrpeCBASSE8sSc1OTS1ILYovKs1J LT7EyMTBKdXAmDuNI/hXZOA9r64u49XiRxt5et0PGwqVzpr3bc9/S474+Qc7mK+t+izDtj0x QsxGRS36/acTGn7v026r/+RP4Wte1Ga0PiuJe25KQeSbT26H9BVu9i11WivIUN/N2BNmE63b 2pH7nO3ssdJ9jw14zFsWKfDVJ25bevthxDGZRyw6gitvHEtSYinOSDTUYi4qTgQAiIVPPqIC AAA= X-Mailman-Approved-At: Sat, 26 Jan 2013 10:11:30 -0800 Cc: Dean Cheng , Alvaro Retana , "behave@ietf.org" , Andrew Sullivan , Mohamed Boucadair Subject: Re: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 16:54:58 -0000 On Jan 26, 2013, at 11:12 AM, Brian E Carpenter wrote: > On 24/01/2013 21:45, Acee Lindem wrote: >> On Jan 24, 2013, at 4:22 PM, Andrew Sullivan wrote: >>=20 >>> On Thu, Jan 24, 2013 at 08:45:42PM +0000, Acee Lindem wrote: >>>> Sufficient time has been provided for input and we've already gone thr= ough several review cycles in the OSPF WG. We provided the BEHAVE the oppor= tunity to comment since the draft is based on RFC 6052 (which was in my ori= ginal E-mail but clipped from your reply). You are welcome to review it as = part of the IETF last call.=20 >>>>=20 >>> Well, I can provide this review: I don't understand the value of the >>> proposal. >>>=20 >>> As nearly as I can tell, it is a redundant mechanism that does not >>> push existing v4-only networks towards IPv6 deployment. To the extent >>> that's true, I don't think it should be pursued. >>=20 >> Using this reasoning, the same could be said for RFC 6052 and RFC 6145. = Given that the RFC 6052/RFC 6145 mechanisms exist, this is merely an inform= ational draft describing how one could use OSPFv3 address families to route= between the IPv4 and IPv6 domains.=20 >=20 > I think the problem is that the scenario analysis isn't adequate. > There is no discussion of the relationship with the various > scenarios described in RFC 6144 - this seems to be an extension > from there, but it should be explained. >=20 > It would be nice to hear how it compares to draft-ietf-v6ops-464xlat. > The latter is not aimed at IPv4 peer-to-peer communication, but > only at client-server with no inbound connections. Is this different? >=20 > Given that "the IPv4 and IPv6 header translation performed in both > directions by the AFXLBR is stateless", does that imply that only > global IPv4 addresses are supported and the solution is transparent > to ports and upper layers? I'll defer to the authors.=20 Thanks, Acee >=20 > Brian From cb.list6@gmail.com Sat Jan 26 10:12:31 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A3B21F856D for ; Sat, 26 Jan 2013 10:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.323 X-Spam-Level: X-Spam-Status: No, score=-3.323 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se5f8-ePtEWu for ; Sat, 26 Jan 2013 10:12:31 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 93C2321F8563 for ; Sat, 26 Jan 2013 10:12:30 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id gm6so2274100lbb.12 for ; Sat, 26 Jan 2013 10:12:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hygDly2uI4NBSAWqzbbXRndpfk1eA6p8O8b02NgtdW4=; b=lsODCW6cXIfC0IWlc4/j98yUNfMw6FEdY4ZnOgWx6e+Xa+Pj3HeJ1IQPqZaVH7A593 nQzkyh1Cewpj5Nq0ukiFSioGNxMSGnmiXwFEdH+TM5USQTwI/L5ELqSbfSxc/TClr7ud i4GKROUx6RarPttj1QSUREiaiMnfYK/x39ELmuSADj61iWJpxKhk8ustGcOICEC7tmSY IFHLsrvAiuyhtYfsmlVPjdHKwYJCleoD5a69PlViXU2AllpyIvkp5XE2G/2giFzxybq0 /3Lr/cjnlLkSWd6SIrl0O5jSCS2gEpBCHKivpCLhVXAHJbGhkwfe+31UEAcu5EwFLPLx nV0Q== MIME-Version: 1.0 X-Received: by 10.152.111.102 with SMTP id ih6mr8533422lab.20.1359223944494; Sat, 26 Jan 2013 10:12:24 -0800 (PST) Received: by 10.112.7.165 with HTTP; Sat, 26 Jan 2013 10:12:24 -0800 (PST) Received: by 10.112.7.165 with HTTP; Sat, 26 Jan 2013 10:12:24 -0800 (PST) In-Reply-To: <51040083.3080600@gmail.com> References: <94A203EA12AECE4BA92D42DBFFE0AE4708637E@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE470ABBE3@eusaamb101.ericsson.se> <20130124203547.GA11097@mx1.yitter.info> <94A203EA12AECE4BA92D42DBFFE0AE470ABCF7@eusaamb101.ericsson.se> <20130124212211.GD11097@mx1.yitter.info> <94A203EA12AECE4BA92D42DBFFE0AE470ABEDA@eusaamb101.ericsson.se> <51040083.3080600@gmail.com> Date: Sat, 26 Jan 2013 10:12:24 -0800 Message-ID: From: Cameron Byrne To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f46d04088f7b61be1e04d434fcda Cc: Acee Lindem , "<, behave@ietf.org>, " , Andrew Sullivan Subject: Re: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 18:12:32 -0000 --f46d04088f7b61be1e04d434fcda Content-Type: text/plain; charset=ISO-8859-1 Sent from ipv6-only Android On Jan 26, 2013 8:12 AM, "Brian E Carpenter" wrote: > > On 24/01/2013 21:45, Acee Lindem wrote: > > On Jan 24, 2013, at 4:22 PM, Andrew Sullivan wrote: > > > >> On Thu, Jan 24, 2013 at 08:45:42PM +0000, Acee Lindem wrote: > >>> Sufficient time has been provided for input and we've already gone through several review cycles in the OSPF WG. We provided the BEHAVE the opportunity to comment since the draft is based on RFC 6052 (which was in my original E-mail but clipped from your reply). You are welcome to review it as part of the IETF last call. > >>> > >> Well, I can provide this review: I don't understand the value of the > >> proposal. > >> > >> As nearly as I can tell, it is a redundant mechanism that does not > >> push existing v4-only networks towards IPv6 deployment. To the extent > >> that's true, I don't think it should be pursued. > > > > Using this reasoning, the same could be said for RFC 6052 and RFC 6145. Given that the RFC 6052/RFC 6145 mechanisms exist, this is merely an informational draft describing how one could use OSPFv3 address families to route between the IPv4 and IPv6 domains. > > I think the problem is that the scenario analysis isn't adequate. > There is no discussion of the relationship with the various > scenarios described in RFC 6144 - this seems to be an extension > from there, but it should be explained. > > It would be nice to hear how it compares to draft-ietf-v6ops-464xlat. > The latter is not aimed at IPv4 peer-to-peer communication, but > only at client-server with no inbound connections. Is this different? > > Given that "the IPv4 and IPv6 header translation performed in both > directions by the AFXLBR is stateless", does that imply that only > global IPv4 addresses are supported and the solution is transparent > to ports and upper layers? > > Brian > 464xlat implies stateful 6146 translation while this only uses 6145. That said, it seems more similar to map-t CB _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --f46d04088f7b61be1e04d434fcda Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Sent from ipv6-only Android
On Jan 26, 2013 8:12 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: >
> On 24/01/2013 21:45, Acee Lindem wrote:
> > On Jan 24, 2013, at 4:22 PM, Andrew Sullivan wrote:
> >
> >> On Thu, Jan 24, 2013 at 08:45:42PM +0000, Acee Lindem wrote:<= br> > >>> Sufficient time has been provided for input and we've= already gone through several review cycles in the OSPF WG. We provided the= BEHAVE the opportunity to comment since the draft is based on RFC 6052 (wh= ich was in my original E-mail but clipped from your reply). You are welcome= to review it as part of the IETF last call.
> >>>
> >> Well, I can provide this review: I don't understand the v= alue of the
> >> proposal.
> >>
> >> As nearly as I can tell, it is a redundant mechanism that doe= s not
> >> push existing v4-only networks towards IPv6 deployment. =A0To= the extent
> >> that's true, I don't think it should be pursued.
> >
> > Using this reasoning, the same could be said for RFC 6052 and RFC= 6145. Given that the RFC 6052/RFC 6145 mechanisms exist, this is merely an= informational draft describing how one could use OSPFv3 address families t= o route between the IPv4 and IPv6 domains.
>
> I think the problem is that the scenario analysis isn't adequate.<= br> > There is no discussion of the relationship with the various
> scenarios described in RFC 6144 - this seems to be an extension
> from there, but it should be explained.
>
> It would be nice to hear how it compares to draft-ietf-v6ops-464xlat.<= br> > The latter is not aimed at IPv4 peer-to-peer communication, but
> only at client-server with no inbound connections. Is this different?<= br> >
> Given that "the IPv4 and IPv6 header translation performed in bot= h
> directions by the AFXLBR is stateless", does that imply that only=
> global IPv4 addresses are supported and the solution is transparent > to ports and upper layers?
>
> =A0 =A0 Brian
>

464xlat implies stateful 6146 translation while this only us= es 6145.

That said, it seems more similar to map-t

CB _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave

--f46d04088f7b61be1e04d434fcda-- From dean.cheng@huawei.com Mon Jan 28 15:14:19 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CAE21F8596 for ; Mon, 28 Jan 2013 15:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+zTl874aHZu for ; Mon, 28 Jan 2013 15:14:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA2D521E8030 for ; Mon, 28 Jan 2013 15:14:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANY39100; Mon, 28 Jan 2013 23:14:16 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 28 Jan 2013 23:13:47 +0000 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 28 Jan 2013 23:14:15 +0000 Received: from SZXEML523-MBX.china.huawei.com ([169.254.3.137]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.007; Tue, 29 Jan 2013 07:14:09 +0800 From: Dean cheng To: Brian E Carpenter , Acee Lindem Thread-Topic: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 Thread-Index: AQHN++AEX3lXB2VG4k6/jeMNC+6QsJhfO/5w Date: Mon, 28 Jan 2013 23:14:10 +0000 Message-ID: References: <94A203EA12AECE4BA92D42DBFFE0AE4708637E@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE470ABBE3@eusaamb101.ericsson.se> <20130124203547.GA11097@mx1.yitter.info> <94A203EA12AECE4BA92D42DBFFE0AE470ABCF7@eusaamb101.ericsson.se> <20130124212211.GD11097@mx1.yitter.info> <94A203EA12AECE4BA92D42DBFFE0AE470ABEDA@eusaamb101.ericsson.se> <51040083.3080600@gmail.com> In-Reply-To: <51040083.3080600@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" , Andrew Sullivan Subject: Re: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 23:14:19 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Brian E Carpenter > Sent: Saturday, January 26, 2013 8:13 AM > To: Acee Lindem > Cc: ; Andrew Sullivan > Subject: Re: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft- > ietf-ospf-ipv4-embedded-ipv6-routing-05 >=20 > On 24/01/2013 21:45, Acee Lindem wrote: > > On Jan 24, 2013, at 4:22 PM, Andrew Sullivan wrote: > > > >> On Thu, Jan 24, 2013 at 08:45:42PM +0000, Acee Lindem wrote: > >>> Sufficient time has been provided for input and we've already gone > through several review cycles in the OSPF WG. We provided the BEHAVE > the opportunity to comment since the draft is based on RFC 6052 (which > was in my original E-mail but clipped from your reply). You are welcome > to review it as part of the IETF last call. > >>> > >> Well, I can provide this review: I don't understand the value of the > >> proposal. > >> > >> As nearly as I can tell, it is a redundant mechanism that does not > >> push existing v4-only networks towards IPv6 deployment. To the > extent > >> that's true, I don't think it should be pursued. > > > > Using this reasoning, the same could be said for RFC 6052 and RFC > 6145. Given that the RFC 6052/RFC 6145 mechanisms exist, this is merely > an informational draft describing how one could use OSPFv3 address > families to route between the IPv4 and IPv6 domains. >=20 > I think the problem is that the scenario analysis isn't adequate. > There is no discussion of the relationship with the various > scenarios described in RFC 6144 - this seems to be an extension > from there, but it should be explained. >=20 We can add some text to clarify this if that helps; in fact the=20 scenario we described here is exactly the same as that in RFC5565=20 (published 2 years earlier than RFC6144), as so stated in Section 1.2. > It would be nice to hear how it compares to draft-ietf-v6ops-464xlat. > The latter is not aimed at IPv4 peer-to-peer communication, but > only at client-server with no inbound connections. Is this different? >=20 There are differences as said here also in Cameron Byrne's email. We=20 can add some text to explain; we did not intend to run a general=20 comparison with others here though. > Given that "the IPv4 and IPv6 header translation performed in both > directions by the AFXLBR is stateless", does that imply that only > global IPv4 addresses are supported and the solution is transparent > to ports and upper layers? This draft describes an application based on RFC6052 and RFC6045 along=20 with OSPFv3 MI/MT flavor, and so restrictions as defined in those are appli= ed,=20 including that the use of well-known IPv6 address prefix not to be used=20 to represent non-global IPv4 addresses, and the translation does not=20 touch those beyond IP header. Dean >=20 > Brian > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From brian.e.carpenter@gmail.com Tue Jan 29 00:02:46 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49CC21F8887 for ; Tue, 29 Jan 2013 00:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVec7uAYJsW6 for ; Tue, 29 Jan 2013 00:02:46 -0800 (PST) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) by ietfa.amsl.com (Postfix) with ESMTP id 99C8721F87E7 for ; Tue, 29 Jan 2013 00:02:45 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id i1so67368eaa.32 for ; Tue, 29 Jan 2013 00:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HQ7Sqng+BtLgzS3LY8mDO3j64l2okyrcyEWlyf9ERYI=; b=erMmPzY92TwbVhfwOZQ06o+TqH5gW2BkPkRItaOiMfhvnOKKOwq4HKJHTiLzunXAH8 Uoh+i60NP3LwJiVN7yBX8eSejN2/+SkKlDarKVfpZvJUs0Lew+nhojHV9D74Wp9qpgIS wssYoTG/fq4mgKeMRGeasEwINEPhJL2ljaui+PSPJFuZpt9XkWkw7vbyn7KU9LwgNG4z M+kisIJQLtyEyhtSnmkVAUDXeKY7/cv6+4TMD/FAQX3zVO2PpQNGukyf57eDMRNcdSww xIahHuUAguhkS2q79UoTHwPAuFKLRRYEu8RcASU6XAilPUCjg3GjfeqXhX6TCzb+j+p4 KGCQ== X-Received: by 10.14.223.137 with SMTP id v9mr887044eep.22.1359446564775; Tue, 29 Jan 2013 00:02:44 -0800 (PST) Received: from [192.168.1.65] (host-2-102-217-172.as13285.net. [2.102.217.172]) by mx.google.com with ESMTPS id 43sm19427129eed.10.2013.01.29.00.02.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 00:02:43 -0800 (PST) Message-ID: <51078228.3010501@gmail.com> Date: Tue, 29 Jan 2013 08:02:48 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean cheng References: <94A203EA12AECE4BA92D42DBFFE0AE4708637E@eusaamb101.ericsson.se> <94A203EA12AECE4BA92D42DBFFE0AE470ABBE3@eusaamb101.ericsson.se> <20130124203547.GA11097@mx1.yitter.info> <94A203EA12AECE4BA92D42DBFFE0AE470ABCF7@eusaamb101.ericsson.se> <20130124212211.GD11097@mx1.yitter.info> <94A203EA12AECE4BA92D42DBFFE0AE470ABEDA@eusaamb101.ericsson.se> <51040083.3080600@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Acee Lindem , "" , Andrew Sullivan Subject: Re: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft-ietf-ospf-ipv4-embedded-ipv6-routing-05 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 08:02:46 -0000 Dean, Thanks. IMHO it's very important to get these points about the deployment scenario very clear in the document. Otherwise the spec could be widely misinterpreted as providing something more than it does. Regards Brian On 28/01/2013 23:14, Dean cheng wrote: >> -----Original Message----- >> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On >> Behalf Of Brian E Carpenter >> Sent: Saturday, January 26, 2013 8:13 AM >> To: Acee Lindem >> Cc: ; Andrew Sullivan >> Subject: Re: [BEHAVE] Routing for IPv4-embedded IPv6 Packets - draft- >> ietf-ospf-ipv4-embedded-ipv6-routing-05 >> >> On 24/01/2013 21:45, Acee Lindem wrote: >>> On Jan 24, 2013, at 4:22 PM, Andrew Sullivan wrote: >>> >>>> On Thu, Jan 24, 2013 at 08:45:42PM +0000, Acee Lindem wrote: >>>>> Sufficient time has been provided for input and we've already gone >> through several review cycles in the OSPF WG. We provided the BEHAVE >> the opportunity to comment since the draft is based on RFC 6052 (which >> was in my original E-mail but clipped from your reply). You are welcome >> to review it as part of the IETF last call. >>>> Well, I can provide this review: I don't understand the value of the >>>> proposal. >>>> >>>> As nearly as I can tell, it is a redundant mechanism that does not >>>> push existing v4-only networks towards IPv6 deployment. To the >> extent >>>> that's true, I don't think it should be pursued. >>> Using this reasoning, the same could be said for RFC 6052 and RFC >> 6145. Given that the RFC 6052/RFC 6145 mechanisms exist, this is merely >> an informational draft describing how one could use OSPFv3 address >> families to route between the IPv4 and IPv6 domains. >> >> I think the problem is that the scenario analysis isn't adequate. >> There is no discussion of the relationship with the various >> scenarios described in RFC 6144 - this seems to be an extension >> from there, but it should be explained. >> > > We can add some text to clarify this if that helps; in fact the > scenario we described here is exactly the same as that in RFC5565 > (published 2 years earlier than RFC6144), as so stated in Section 1.2. > >> It would be nice to hear how it compares to draft-ietf-v6ops-464xlat. >> The latter is not aimed at IPv4 peer-to-peer communication, but >> only at client-server with no inbound connections. Is this different? >> > > There are differences as said here also in Cameron Byrne's email. We > can add some text to explain; we did not intend to run a general > comparison with others here though. > >> Given that "the IPv4 and IPv6 header translation performed in both >> directions by the AFXLBR is stateless", does that imply that only >> global IPv4 addresses are supported and the solution is transparent >> to ports and upper layers? > > This draft describes an application based on RFC6052 and RFC6045 along > with OSPFv3 MI/MT flavor, and so restrictions as defined in those are applied, > including that the use of well-known IPv6 address prefix not to be used > to represent non-global IPv4 addresses, and the translation does not > touch those beyond IP header. > > Dean > >> Brian >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > From iljitsch@muada.com Tue Jan 29 02:55:09 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1A621F87E4 for ; Tue, 29 Jan 2013 02:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnKkYaq04M2V for ; Tue, 29 Jan 2013 02:55:09 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB6D21F87E1 for ; Tue, 29 Jan 2013 02:55:08 -0800 (PST) Received: from [192.168.178.12] (53564520.cm-6-7b.dynamic.ziggo.nl [83.86.69.32]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id r0TAol2F087491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Jan 2013 11:50:48 +0100 (CET) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Iljitsch van Beijnum In-Reply-To: <20130125235855.0F8AB2E75690@drugs.dv.isc.org> Date: Tue, 29 Jan 2013 11:55:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <02FA9F92-D4AD-4DD1-9A4B-8936E4A724D6@muada.com> References: <795848A6-545B-41A7-9E89-B8339B0F7CDE@muada.com> <50F43ED1.4020704@viagenie.ca> <20130125140908.62F512E741B3@drugs.dv.isc.org> <20130125235855.0F8AB2E75690@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) Cc: behave@ietf.org Subject: Re: [BEHAVE] Translating proto 41 tunnels in CGNAT? X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 10:55:09 -0000 On 26 jan 2013, at 0:58, Mark Andrews wrote: >> Ideally, this would be a dynamic longest match first, so a single = address can >> set up a mapping for an entire /48 or /56 until a different host uses = an add >> ress in a different /64 but in the same /48 or /56. > Which will result in packets being sent to the wrong internal machine. Unreliable datagram service. All part of the game. Misdelivery of a few random packets that aren't part of two-way = communication can happen, yes. >>> So for this to work the NAT would need to detect the https session >>> and the force protocol 41 traffic to use the same IPv4 address. >> No, that doesn't work. The issue with protocol 41 is that it has no = port numb >> ers, so without looking inside the inner IPv6 header, there's nothing = to demu >> ltiplex packets towards different users behind the same NAT. > And I'm showing you how protocol 41 tunnels are established today. I've never done it that way, but if you say so. That doesn't change the fact that there are no port numbers in protocol = 41 so HTTPS activity can't create the actual CGNAT mappings. > You are the one claiming that this will work with existing setups. Yes. > Today the https source address and the protocol 41 source address > are constrained to be the same address 99.99% of the time as the > customer has a single IPv4 address. This relationship is used by > the tunnel establishment process. Right. Except with CGNAT the IPv4 address that is "used by the tunnel = establishment process" is the CGNAT's external IPv4 address. So as = before, the tunnel broker knows where to send its protocol 41 = encapsulated packets. The question is what happens once the packets arrive at the CGNAT. If = the CGNAT takes a look at the IPv6 addresses embedded in the inner IPv6 = header, then the CGNAT can NAT the packets, and of course all the = limitations of NAT apply, except that the inner IPv6 addresses are = (presumably) globally unique, unlike port numbers.=