Re: [Int-area] draft-george-ipv6-required

2011-01-16 Thread Joel Jaeggli
On 1/10/11 7:36 PM, Ed Jankiewicz wrote:
 upon reflection, I agree that it would be unnecessary and inappropriate
 to generate a petition within IETF.  The process is built on consensus,
 not name-checking.
 
 Suffice it to say I support this work being discussed within Intarea and
 v6ops, including time on the agenda in Prague, and eventual adoption as
 a WG or IAB publication.
 
 I also agree with a previous comment that this draft should be kept very
 simple with a small number of essential references, e.g. to the IPv6
 Node Requirements (as revised).  That is the current best definition of
 what is required for IPv6.  If it is insufficient as is, and needs to
 be replaced by a standards track definition, that would take some
 effort, and that can be discussed as well.  I would prefer that we
 publish the current RFC 4294 update draft before we open that can of worms.
 
 The question of parity is very complex and difficult to define. 

more to the point consensus on what constitutes  is a discussion that's
pretty easy to rathole. A statement that is simplistic and open to
interpretation may not achieve all that you want at the same time the
resulting statement may be more readily achievable and we have documents
like for example the cpe drafts to addresses.

Idealy this document is:

1. discussed now both here and the int-area.
2. presented in prague
3. accepted as a wg document where we deem appropiate
4. last called

 The
 concerns that some things are not directly comparable, or that there are
 things that have become accepted in IPv4 that some don't want to
 replicate in IPv6, versus the sense that the lack of any feature
 (standard or not) will be a disincentive to IPv6 adoption - it's not
 clear how these can be reconciled.
 
 On 1/10/2011 11:29 AM, George, Wes E [NTK] wrote:
 Shortened the subject line a bit

 From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On
 Behalf
 Of Ed Jankiewicz
 Sent: Friday, January 07, 2011 3:11 PM
 To: int-area@ietf.org; IPv6 Operations
 Subject: Re: [Int-area] IP-capable nodes must support IPv6 - new
 draft-george-ipv6-required

 I agree so strenuously that I half-jokiningly would like to be listed
 as a
 coauthor, and I bet there are anumber of other folks on these lists
 that
 would feel the same way.  Perhaps a better suggestion would be
 toinclude an
 appendix with the name and affiliation of everyone who is willing to
 sign-on
 to ratify thisrecommendation.
 [WES] If I'm interpreting this right, this would sort of be like a
 petition
 with lots of signatures, or one of those open letters to the
 $government_functionary signed by lots of important people you see
 published
 in full-page newspaper ads? I assume that this is generally a way of more
 concretely documenting support for this proposal beyond the IETF's
 standard
 rough consensus in a WG meeting or on-list.
 I'm open to this, but is there any precedent for it? Do we want to set a
 precedent that if we *really* mean something, we take steps to more
 thoroughly
 document that support within a draft? Those in support can already
 have their
 support immortalized in the pages of the email list archives complete
 with
 their choice of editorialization...
 And regarding affiliation - IETF typically shies away from making a
 big deal
 of affiliation, since most of its members are not really authorized to
 represent the company that pays the bills in any official public
 capacity.
 Yes, they are representatives of that company, but they are mostly
 speaking
 for themselves with the interests of their company informing those
 comments -
 it's not like there's a way to get every email and comment at the mic
 approved
 by PR first :-)

 An IAB statement of support would perhaps be a good way to add weight
 to this
 recommendation, but I'm content to start with statements of support
 for WG
 adoption and advancement to RFC status and see where it goes from there.

 Wes George
 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


Re: [Int-area] [v6ops] End-to-end address transparency

2011-01-16 Thread Joel Jaeggli
On 1/10/11 9:50 PM, Fernando Gont wrote:
 On 10/01/2011 05:43 p.m., Mark Smith wrote:
 
 The e2e transparency that IPv4 had lost, and IPv6 restores, is
 ADDRESS transparency: source and destination addresses seen by a
 destination are the same as those set by the source. 

 IPv6 restores this to the extent that NAT66 is not deployed. My take is
 that NAT66 *will* be deployed. 

 How do you know? What evidence do you have?
 
 Talking to vendors, some operators, etc.
 
 Google for ipv6 nat or the like, and you'll see some of the people
 that are publicly interested in this feature.

It's a basic and necessary feature of ipv6-supporting loadbalancer devices.

Given that header rewriting, and state-tracking are basic firewall
functions for v4 and v6 you really aren't very far conceptually or
implementation-wise from a nat66 feature.

The question is what's it a point solution for. If the problem is, you
gave me one ip address and i need more than that something is badly wrong.

 
 
 -- So, I don't think you can rely IPv6 on
 restoring address transparency.

 - This is needed
 in particular for Header Authentication of IPsec. 

 But you can still use UDP encapsulation.

 UDP encapsulation of IPsec is a work around, specifically to get around
 the problems of lack of IPv4 address transparency i.e. NAT. It isn't an
 acceptable answer when NAT doesn't need to exist.
 
 You're assuming that the only motivation to have NATs is address
 exhaustion -- but IMO, it isn't.
 
 Thanks,

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


Re: [Int-area] [v6ops] End-to-end address transparency

2011-01-16 Thread Mark Smith
On Sun, 16 Jan 2011 13:37:07 +0100
Joel Jaeggli joe...@bogus.com wrote:

 On 1/10/11 9:50 PM, Fernando Gont wrote:
  On 10/01/2011 05:43 p.m., Mark Smith wrote:
  
  The e2e transparency that IPv4 had lost, and IPv6 restores, is
  ADDRESS transparency: source and destination addresses seen by a
  destination are the same as those set by the source. 
 
  IPv6 restores this to the extent that NAT66 is not deployed. My take is
  that NAT66 *will* be deployed. 
 
  How do you know? What evidence do you have?
  
  Talking to vendors, some operators, etc.
  
  Google for ipv6 nat or the like, and you'll see some of the people
  that are publicly interested in this feature.
 
 It's a basic and necessary feature of ipv6-supporting loadbalancer devices.
 

I don't think that is necessarily the case either. A group of hosts
with the same downstream address (the global one announced in DNS), and
a router-type device (i.e. isn't assigned the global address announced
in DNS) spreading traffic across them such that the same session landed
on the same downstream host would provide load balancing without NAT -
effectively a more advanced version of anycast where all hosts are
active, and there is more intelligence in the selection of to which
anycast host the traffic is sent by the upstream router, spreading the
load. 


 Given that header rewriting, and state-tracking are basic firewall
 functions for v4 and v6 you really aren't very far conceptually or
 implementation-wise from a nat66 feature.
 
 The question is what's it a point solution for. If the problem is, you
 gave me one ip address and i need more than that something is badly wrong.
 
  
  
  -- So, I don't think you can rely IPv6 on
  restoring address transparency.
 
  - This is needed
  in particular for Header Authentication of IPsec. 
 
  But you can still use UDP encapsulation.
 
  UDP encapsulation of IPsec is a work around, specifically to get around
  the problems of lack of IPv4 address transparency i.e. NAT. It isn't an
  acceptable answer when NAT doesn't need to exist.
  
  You're assuming that the only motivation to have NATs is address
  exhaustion -- but IMO, it isn't.
  
  Thanks,
 
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area