Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2

Hi Mark,

Thanks much for sharing the detailed experience.

> These questions sound a bit to me like you haven't added a ULA prefix to an
> IPv6 network you're commonly using. So if you haven't, I think you should -
> 'the proof of the pudding is in the eating'.

[Bing] We did some test in the lab, mostly on ULA+PA, and it worked well, just as you experienced. And there were also some feedbacks of successful usage of ULAs in home networks in the mailing list. ULA+PA is also recommended by the Homenet WG. Personally I believe ULA+PA in home networks has got sufficient proof.

However, we haven't had plenty of experience of using ULAs in a real production network, e.g. a JANOG event, or a middle/big size enterprise network or ISP networks .etc. That's why the WG suggested the draft to be "Informational", and to change the key words "recommendation"/"guidelines" to "considerations" in the draft.

So I think experiences like JANOG34 would help us to proof more about the statements in the draft.
If we could have more experiences like this in the future, maybe we can change the document to BCP.

Best regards,
Bing

> Regards,
> 
> Mark.
> 
> > Best regards,
> > Bing
> >
> >
> >>  -----Original Message-----
> >>  From: Fred Baker (fred) [mailto:fred@cisco.com]
> >>  Sent: Saturday, June 28, 2014 8:58 AM
> >>  To: Shishio Tsuchiya (shtsuchi)
> >>  Cc: Liubing (Leo); kshimizu@juniper.net; v6ops@ietf.org;
> >> i18n@janog.gr.jp
> >>  Subject: Re: [v6ops] JANOG34 provides 3.2.1 and 3.2.2
> >>
> >>
> >>  On Jun 27, 2014, at 3:27 AM, Shishio Tsuchiya <shtsuchi@cisco.com>
> > wrote:
> >>
> >>  > Leo and v6ops
> >>  > F.Y.I
> >>  > JANOG(JApan Network Operator's Group) decided to provide ula
> > address
> >>  to the JANOG34 conference network.
> >>  > http://www.janog.gr.jp/en/index.php?JANOG34_Meeting
> >>  >
> >>  > They will provide 3.2.1. ULA-only Deployment and 3.2.2. ULA along
> >> with  GUA.
> >>  >
> >>
> >> http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations
> >> -02
> >>  >
> >>  > If you would like to confirm something on the network , please let
> >> me  know.
> >>
> >>  Thanks for this.
> >>
> >>  I would expect that the key things to prove are the statements in
> >> the
> > draft.
> >>  Also, any observations that might come up would be useful. For
> >> example,  was it fair to say that the network that was isolated remained
> isolated?
> > Did
> >>  using a ULA and a GUA on a globally-accessible network cause any
> issues?
> >>  What, if anything, was necessary in the router(s) in question to
> >> prevent
> > hosts
> >>  from using ULA source addresses to connect to GUA addresses? Did
> >> hosts in  fact form both ULA and GUA-based addresses and use them
> >> appropriately  when connecting to applications inside and outside the
> network?
> >>
> >>  What one might hope would be that ULA-based addresses were used to
> >> connect to other ULA-based addresses, as their bit strings were most
> > similar,
> >>  and GUA-based addresses were used to connect to other GUA-based
> >> addresses, for the same reason. One might hope that ULA prefixes were
> >> not  announced in BGP without needing extra thought, and that if they
> >> were  announced, they were not accepted. One might further hope that
> >> when a  ULA was not announced into a neighboring domain, a packet
> >> sent to the ULA  prefix didn't cross the domain boundary.
> >>
> >>  Of course, we need to hear about any extra work that was required,
> >> and any  problems that arose. And we need to understand if the
> >> deployment of a ULA  prefix necessarily implied the deployment of an
> >> IPv6/IPv6 NAT or NAPT. I  don't expect that it will and am certainly
> >> not asking for it to, but
> > that
> >>  expectation has been promoted.
> >>
> >>  JANOG will be Wednesday-Friday the week before IETF 90, and v6ops
> >> will  meet Monday and Tuesday. It would be nice if someone could make
> >> a point  of reporting on the experiment.
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> >